Speed, and to a lesser extent memory. The biggest advantage is it allows short circuiting with ridiculous speedups for certain cases. It also removes intermediate arrays/bandwidth. There is some SIMD speedup but thats a relatively small benefit.
On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan < > harrigan.matt...@gmail.com> wrote: > >> PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs >> such as " all equal". The functionality has been mentioned quite a few >> times on this list. Many implementations are in the PR and they are decent >> IMHO. The hard part is the API and current ufunc code. Initially I >> thought they would be top level functions, ie np.all_equal, but there >> appears to be general consensus that they should be ufunc methods, ie >> np.equal.all. Its not clear to me at least how that should be done. >> Adding all, any, and first methods to all ufuncs seems bad. Some sort of >> monkeypatch hack also seems bad. Rewriting the ufunc code to make the >> methods specific to each ufunc, likely breaking the abi/api, is a big >> effort. Suggestions welcome. Thank you. >> > > Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I > suppose the argument in favor is decreasing the number of function names, > which also has its proponents. What is the gain here in making them stand > alone functions, more speed, possible SIMD speedups, etc.? > > <snip> > > Chuck > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
