MAINT: Generalize and shorten the ufunc "trivially iterable" path

[seberg]

This avoids the large macros designed for specific number of
arguments and generalizes it to all ufuncs with a single output
(Instead of only 1 and 2 operand input ufuncs.)

That is not a big generalization, but the code actually shortens
and while it is slightly more complex in umath itself, it avoids
the fairly complex macros as well.

---

This code is very slightly useful to me, because I have to push the innerloop resolution down until after fixed_strides is defined. Which currently happens in two spots (for 1 or 2 input ufuncs). For a bit I thought there was more to it, so this fell out.

I currently slightly prefer it though, and think it is probably easier to understand then PyArray_TRIVIALLY_ITERABLE_TRIPLE... So would like to continue my work based off this (and this being merged soon 🤞).

[seberg]

Hmm, I will undo this... Its a bit tricky (correct, but its not really better as is, and the points in the code still using it should maybe just be modified).

The point is that if the arrays are 1-D, they don't have to be contiguous at all, so this check could be skipped entirely if both are 1-D. My new code does this, which makes things like:

arr_1d[::2] + arr1_d[1::2]

or any other such operation where one of the operands is 1-D strided much faster (mainly lower overhead, but that can be a factor of 2 for small additions). Making it == works for the above, but won't work for:

arr_1d[::2] + other_arr_1d_contiguous

since then the contiguity doesn't match... that is why I think I will undo it to avoid confusion.

[seberg]

We never care about overlap in read-only operands, so these are no-ops. (in the case of nin=2, nout=1 operations, which is the only place where we used this).

[seberg]

Example of the previously missed trivial-iteration case:

In [1]: arr = np.arange(10)

In [2]: arr2 = np.arange(20)[::2]

In [3]: %timeit np.add(arr, arr2)
343 ns ± 0.406 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Before the change:

785 ns ± 4.66 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

EDIT: Other cases seem to be stable.

[mhvk]

I think this is a lot nicer - I recall being confused about the macros but here the code is quite simple and nice.

[seberg]

This maybe the trickiest logic in the whole PR. And maybe it should use an & (the code in NewFromDescr is weird about this). But the test suit unsurprisingly finds many errors if you just pass 0 always here, so its fine.

[rossbar]

There are many details of ufuncs that I don't have a firm grasp of, but it is much easier to grok try_trivial_single_output_loop than chunk it replaces 👍

[mattip]

Thanks @seberg