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.vankerkw...@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.matt...@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.har...@gmail.com> wrote:
>>
>>>
>>>
>>> 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
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
