[Numpy-discussion] PR Cleanup

[Matthew Harrigan]

Marten,
I think a ufunc route is pretty straightforward assuming there is a higher
level function.  It would be something like this:

def wrapper_for_all_equal(x, y):
    return np.private_ufunc_all_equal(*np.broadcast_arrays(x, y))

The largest outstanding issue I see are what the api should be.  There was
concern about adding too many functions to the already crowded numpy
namespace.

On Tue, Sep 25, 2018 at 9:25 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20180927/35befb5d/attachment.html>