It also appears that cumsum has a lot of unnecessary overhead over add.accumulate:
In [51]: %timeit np.add.accumulate(a) The slowest run took 46.31 times longer than the fastest. This could mean that an intermediate result is being cached 1000000 loops, best of 3: 372 ns per loop In [52]: %timeit np.cum np.cumprod np.cumproduct np.cumsum In [52]: %timeit np.cumsum(a) The slowest run took 18.44 times longer than the fastest. This could mean that an intermediate result is being cached 1000000 loops, best of 3: 912 ns per loop In [53]: %timeit np.add.accumulate(a.flatten()) The slowest run took 25.59 times longer than the fastest. This could mean that an intermediate result is being cached 1000000 loops, best of 3: 834 ns per loop On Tue, Apr 14, 2015 at 7:42 AM, Neil Girdhar <mistersh...@gmail.com> wrote: > Okay, but by the same token, why do we have cumsum? Isn't it identical to > > np.add.accumulate > > — or if you're passing in multidimensional data — > > np.add.accumulate(a.flatten()) > > ? > > add.accumulate feels more generic, would make the other ufunc things more > discoverable, and is self-documenting. > > Similarly, cumprod is just np.multiply.accumulate. > > Best, > > Neil > > > On Sat, Apr 11, 2015 at 12:49 PM, Nathaniel Smith <n...@pobox.com> wrote: > >> Documentation and a call to warnings.warn(DeprecationWarning(...)), I >> guess. >> >> On Sat, Apr 11, 2015 at 12:39 PM, Neil Girdhar <mistersh...@gmail.com> >> wrote: >> > I would be happy to, but I'm not sure what that involves? It's just a >> > documentation changelist? >> > >> > On Sat, Apr 11, 2015 at 12:29 PM, Nathaniel Smith <n...@pobox.com> >> wrote: >> >> >> >> On Sat, Apr 11, 2015 at 12:06 PM, Neil Girdhar <mistersh...@gmail.com> >> >> wrote: >> >> >> On Wed, Apr 8, 2015 at 7:34 PM, Neil Girdhar <mistersh...@gmail.com >> > >> >> >> wrote: >> >> >> > Numpy's outer product works fine with vectors. However, I seem to >> >> >> > always >> >> >> > want len(outer(a, b).shape) to be equal to len(a.shape) + >> >> >> > len(b.shape). >> >> >> > Wolfram-alpha seems to agree >> >> >> > https://reference.wolfram.com/language/ref/Outer.html with >> respect to >> >> >> > matrix >> >> >> > outer products. >> >> >> You're probably right that this is the correct definition of the >> outer >> >> >> product in an n-dimensional world. But this seems to go beyond being >> >> >> just a bug in handling 0-d arrays (which is the kind of corner case >> >> >> we've fixed in the past); np.outer is documented to always ravel its >> >> >> inputs to 1d. >> >> >> In fact the implementation is literally just: >> >> >> a = asarray(a) >> >> >> b = asarray(b) >> >> >> return multiply(a.ravel()[:, newaxis], b.ravel()[newaxis,:], out) >> >> >> Sebastian's np.multiply.outer is much more generic and effective. >> >> >> Maybe we should just deprecate np.outer? I don't see what use it >> >> >> serves. (When and whether it actually got removed after being >> >> >> deprecated would depend on how much use it actually gets in real >> code, >> >> >> which I certainly don't know while typing a quick email. But we >> could >> >> >> start telling people not to use it any time.) >> >> > >> >> > >> >> > +1 with everything you said. >> >> >> >> Want to write a PR? :-) >> >> >> >> -- >> >> Nathaniel J. Smith -- http://vorpus.org >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> Nathaniel J. Smith -- http://vorpus.org >> _______________________________________________ >> 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
