On Fri, 2013-07-19 at 16:14 +0100, Nathaniel Smith wrote: > On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg > <sebast...@sipsolutions.net> wrote: > > On Thu, 2013-07-18 at 13:52 +0100, Nathaniel Smith wrote: > >> Hi all, > >> <snip> > > What I mean is: Suppose we wrote a gufunc for 'sum', where the > intrinsic operation took a vector and returned a scalar. (E.g. we want > to implement one of the specialized algorithms for vector summation, > like Kahan summation, which can be more accurate than applying scalar > addition repeatedly.) > > Then we'd have: > > np.sum(ones((2, 3))).shape == () > np.add.reduce(ones((2, 3))).shape == (3,) > gufunc_sum(ones((2, 3))).shape == (2,) >
Ah, indeed! So we have a different default behaviour for ufunc.reduce and all other reduce-like functions, didn't realize that. Changing that would be one huge thing... As to implementing such thing as a Kahan summation, it is true, I also can't see how it fits into the machinery. Maybe it shouldn't even be a gufunc, but we rather need a way to specialize the reduction, or tag on more information into the ufunc itself? - Sebastian > These are three names for exactly the same underlying function... but > they all have different defaults for how they vectorize. > > -n > _______________________________________________ > 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