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 <mwi...@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.br...@gmail.com> > > wrote: > > > HI, > > > > On Wed, May 1, 2013 at 9:09 AM, Yaroslav Halchenko <li...@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. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
