<br><br><div class="gmail_quote">On Tue, May 31, 2011 at 8:50 PM, Bruce Southey <span dir="ltr"><<a href="mailto:bsouthey@gmail.com">bsouthey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Tue, May 31, 2011 at 9:26 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, May 31, 2011 at 8:00 PM, Skipper Seabold <<a href="mailto:jsseabold@gmail.com">jsseabold@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, May 31, 2011 at 9:53 PM, Warren Weckesser<br>
>> <<a href="mailto:warren.weckesser@enthought.com">warren.weckesser@enthought.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Tue, May 31, 2011 at 8:36 PM, Skipper Seabold <<a href="mailto:jsseabold@gmail.com">jsseabold@gmail.com</a>><br>
>> > wrote:<br>
>> >> I don't know if it's one pass off the top of my head, but I've used<br>
>> >> percentile for interpercentile ranges.<br>
>> >><br>
>> >> [docs]<br>
>> >> [1]: X = np.random.random(1000)<br>
>> >><br>
>> >> [docs]<br>
>> >> [2]: np.percentile(X,[0,100])<br>
>> >> [2]: [0.00016535235312509222, 0.99961513543316571]<br>
>> >><br>
>> >> [docs]<br>
>> >> [3]: X.min(),X.max()<br>
>> >> [3]: (0.00016535235312509222, 0.99961513543316571)<br>
>> >><br>
>> ><br>
>> ><br>
>> > percentile() isn't one pass; using percentile like that is much slower:<br>
>> ><br>
>> > In [25]: %timeit np.percentile(X,[0,100])<br>
>> > 10000 loops, best of 3: 103 us per loop<br>
>> ><br>
>> > In [26]: %timeit X.min(),X.max()<br>
>> > 100000 loops, best of 3: 11.8 us per loop<br>
>> ><br>
>><br>
>> Probably should've checked that before opening my mouth. Never<br>
>> actually used it for a minmax, but it is faster than two calls to<br>
>> scipy.stats.scoreatpercentile. Guess I'm +1 to fast order statistics.<br>
>><br>
><br>
> So far the biggest interest seems to be in order statistics of various<br>
> sorts, so to speak.<br>
><br>
> Order Statistics<br>
><br>
> minmax<br>
> median<br>
> k'th element<br>
> largest/smallest k elements<br>
><br>
> Other Statistics<br>
><br>
> mean/std<br>
><br>
> Nan functions<br>
><br>
> nanadd<br>
><br>
> Chuck<br>
><br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
><br>
<br>
</div>How about including all or some of Keith's Bottleneck package?<br>
He has tried to include some of the discussed functions and tried to<br>
make them very fast.<br></blockquote><div><br>I don't think they are sufficiently general as they are limited to 2 dimensions. However, I think the moving filters should go into scipy, either in ndimage or maybe signals. Some of the others we can still speed of significantly, for instance nanmedian, by using the new functionality in numpy, i.e., numpy sort has worked with nans for a while now. It looks like call overhead dominates the nanmax times for small arrays and this might improve if the ufunc machinery is cleaned up a bit more, I don't know how far Mark got with that.<br>
<br>One bit of infrastructure that could be generally helpful is low-level support for masked arrays, but that is a larger topic.<br><br>Chuck<br></div></div>