[Numpy-discussion] numpy.mean still broken for largefloat32arrays

Sylvain Corlay sylvain.corlay at gmail.com
Sat Jul 26 15:30:06 EDT 2014


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.eelco at 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.molden at gmail.com>
> wrote:
>>
>> Sturla Molden <sturla.molden at gmail.com> wrote:
>> > Sebastian Berg <sebastian at 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 at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



More information about the NumPy-Discussion mailing list