[Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

Eric Wieser 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>

Rendered here:
> https://github.com/mhvk/numpy/blob/nep-gufunc-signature-enhancement/doc/neps/nep-0020-gufunc-signature-enhancement.rst
> Eric
> 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
>> closure...
>> See https://github.com/numpy/numpy/pull/11297
>> -- Marten
>> _______________________________________________
>> 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/20180610/8425297f/attachment-0001.html>

More information about the NumPy-Discussion mailing list