<div dir="ltr"><div>Hi Matthew,</div><div><br></div><div>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).</div><div><br></div><div>All the best,</div><div><br></div><div>Marten<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <<a href="mailto:harrigan.matthew@gmail.com">harrigan.matthew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <<a href="mailto:harrigan.matthew@gmail.com" target="_blank">harrigan.matthew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">PR <a href="https://github.com/numpy/numpy/pull/8528" target="_blank">8528</a> 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.<br></div></blockquote><div><br></div><div>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.?</div><div><br></div><div><snip></div><div><br></div><div>Chuck  </div></div></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>