[Numpy-discussion] PR Cleanup

[Marten van Kerkwijk]

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.matthew at 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.harris at gmail.com> wrote:
>
>>
>>
>> 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
>>
> _______________________________________________
> 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/8484e8c2/attachment.html>