[Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs
wieser.eric+numpy at gmail.com
Sun Jun 10 19:31:41 EDT 2018
Thanks for the writeup Marten,
Output shape feels very similar to
output dtype to me, so maybe the general way to handle this would be
to make the first callback take the input shapes+dtypes and return the
desired output shapes+dtypes?
This hits on an interesting alternative to frozen dimensions - np.cross
could just become a regular ufunc with signature np.dtype((float64, 3)),
np.dtype((float64, 3)) → np.dtype((float64, 3))
Furthermore, the expansion quickly becomes cumbersome. For instance, for
the all_equal signature of (n|1),(n|1)->() …
I think this is only a good argument when used in conjunction with the
broadcasting syntax. I don’t think it’s a reason for matmul not to have
multiple signatures. Having multiple signatures is an disincentive to
introduced too many overloads of the same function, which seems like a good
thing to me
Summarizing my overall opinions:
- I’m +0.5 on frozen dimensions. The use-cases seem reasonable, and it
seems like an easy-ish way to get them. Allowing ufuncs to natively support
subarray types might be a tidier solution, but that could come down the road
- I’m -1 on optional dimensions: they seem to legitimize creating many
overloads of gufuncs. I’m already not a fan of how matmul has special cases
for lower dimensions that don’t generalize well. To me, the best way to
handle matmul would be to use the proposed __array_function__ to handle
the shape-based special-case dispatching, either by:
- Inserting dimensions, and calling the true gufunc
np.linalg.matmul_2d (which is a function I’d like direct access to
- Dispatching to one of four ufuncs
- Broadcasting dimensions:
- I know you’re not suggesting this but: enabling broadcasting
unconditionally for all gufuncs would be a bad idea, masking linalg bugs.
(although einsum does support broadcasting…)
- Does it really need a per-dimension flag, rather than a global one?
Can you give a case where that’s useful?
- If we’d already made all_equal a gufunc, I’d be +1 on adding
broadcasting support to it
- I’m -0.5 on the all_equal path in the first place. I think we
either should have a more generic approach to combined ufuncs, or just
declare them numbas job.
- Can you come up with a broadcasting use-case that isn’t just
chaining a reduction with a broadcasting ufunc?
On Sun, 10 Jun 2018 at 16:02 Eric Wieser <wieser.eric+numpy at gmail.com>
> On Sun, 10 Jun 2018 at 09:37 Marten van Kerkwijk <
> m.h.vankerkwijk at gmail.com> wrote:
>> OK, I spent my Sunday morning writing a NEP. I hope this can lead to some
>> See https://github.com/numpy/numpy/pull/11297
>> -- Marten
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion