[Numpy-discussion] PR Cleanup

Matthew Harrigan harrigan.matthew at gmail.com
Tue Sep 25 20:24:52 EDT 2018

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.harris at gmail.com>

> On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <
> harrigan.matthew at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/1137cefc/attachment.html>

More information about the NumPy-Discussion mailing list