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
