On Fri, Jul 19, 2013 at 12:10 PM, Sebastian Berg <[email protected]> wrote: > On Fri, 2013-07-19 at 16:14 +0100, Nathaniel Smith wrote: >> On Thu, Jul 18, 2013 at 2:23 PM, Sebastian Berg >> <[email protected]> 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...
I thought reduce, accumulate and reduceat (and map in python) are functions on iterators, and numpy still uses axis=0 to iterate over. related: is there any advantage to np.add.reduce? I find it more difficult to read than sum() and still see it used sometimes. (dot with more than 3 dimension is weird, and I never found a use for it.) Josef > 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 >> [email protected] >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
