Hi Matthew, With the decision not to support broadcasting in ufunc signatures, I think a ufunc route for generally useful all_equal has become hard at the present time. So, as it it seems the only useful route is indeed a separate function... (perhaps in the end we can use stackable ufuncs, which operate in chunks - I have a prototype but it doesn't do reductions yet, so not directly relevant).
All the best, Marten On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <harrigan.matt...@gmail.com> wrote: > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
