[Numpy-discussion] could anyone check on a 32bit system?

[Sebastian Berg]

On Wed, 2013-05-01 at 15:29 -0400, Yaroslav Halchenko wrote:
> just for completeness... I haven't yet double checked if I have done it
> correctly but here is the bisected commit:
> 
> aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1 is the first bad commit
> commit aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1
> Author: Mark Wiebe <mwiebe at enthought.com>
> Date:   Tue Aug 2 13:34:13 2011 -0500
> 
>     ENH: ufunc: Rewrite PyUFunc_Reduce to be more general and easier to adapt to NA masks
>     
>     This generalizes the 'axis' parameter to accept None or a list of
>     axes on which to do the reduction.
> 
> :040000 040000 2bdd71a1ea60c0dbfe370c77f69724fab28038e1 44f54a15f480ccaf519d10e9c42032de86bd0dca M      numpy
> bisect run success
> 
> FWIW ( ;-) ):
> 

There really is no point discussing here, this has to do with numpy
doing iteration order optimization, and you actually *want* this. Lets
for a second assume that the old behavior was better, then the next guy
is going to ask: "Why is np.add.reduce(array, axis=0) so much slower
then reduce(array, np.add)?". This is huge speed improvement by Marks
new iterator for reductions over the slow axes, so instead of trying to
track "regressions" down, I think the right thing is to say kudos for
doing this improvement :).

Just my opinion,

Sebastian

> # git describe --tags aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1
> v0.3.0-7757-gaed9925
> 
> # git describe --tags --contains aed9925a9d5fe9a407d0ca2c65cb577116c4d0f1
> v1.7.0b1~377^2~126
> 
> 
> On Wed, 01 May 2013, Robert Kern wrote:
> 
> > On Wed, May 1, 2013 at 6:24 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> > > HI,
> 
> > > On Wed, May 1, 2013 at 9:09 AM, Yaroslav Halchenko <lists at onerussian.com> wrote:
> 
> > >> 3. they are identical on other architectures (e.g. amd64)
> 
> > > To me that is surprising.  I would have guessed that the order is the
> > > same on 32 and 64 bit, but something about the precision of
> > > intermediate operations is different.   I don't know enough about
> > > amd64 to guess what that could be.  Bradley's suggestion seems kind of
> > > reasonable but it's strange that numpy should use intel-80 bit
> > > intermediate values differently for 32 and 64 bit.
> 
> > "numpy" isn't doing anything different between the two. numpy
> > generates the same C code. The C compiler may be generating different
> > machine instructions for that code on different architectures, even
> > closely related ones like i386 and amd64. Different optimization flags
> > and compiler versions will probably also affect this, not just the
> > target architecture. It's possible that those are actually the source
> > of this observation.