I completely agree with Eelco. I expect numpy.mean to do something simple and straightforward. If the naive method is not well suited for my data, I can deal with it and have my own ad hoc method.
On Sat, Jul 26, 2014 at 3:19 PM, Eelco Hoogendoorn <hoogendoorn.ee...@gmail.com> wrote: > Perhaps I in turn am missing something; but I would suppose that any > algorithm that requires multiple passes over the data is off the table? > Perhaps I am being a little old fashioned and performance oriented here, but > to make the ultra-majority of use cases suffer a factor two performance > penalty for an odd use case which already has a plethora of fine and dandy > solutions? Id vote against, fwiw... > > > On Sat, Jul 26, 2014 at 6:34 PM, Sturla Molden <sturla.mol...@gmail.com> > wrote: >> >> Sturla Molden <sturla.mol...@gmail.com> wrote: >> > Sebastian Berg <sebast...@sipsolutions.net> wrote: >> > >> >> Yes, it is much more complicated and incompatible with naive ufuncs if >> >> you want your memory access to be optimized. And optimizing that is >> >> very >> >> much worth it speed wise... >> > >> > Why? Couldn't we just copy the data chunk-wise to a temporary buffer of >> > say >> > 2**13 numbers and then reduce that? I don't see why we need another >> > iterator for that. >> >> I am sorry if this is a stupid suggestion. My knowledge of how NumPy >> ufuncs >> works could have been better. >> >> Sturla >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@scipy.org >> http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion