[Numpy-discussion] Extending ufunc signature syntax for matmul, frozen dimensions

Matti Picus matti.picus at gmail.com
Tue May 1 01:21:13 EDT 2018

On 01/05/18 01:45, Allan Haldane wrote:
> On 04/29/2018 05:46 AM, Matti Picus wrote:
>> In looking to solve issue #9028 "no way to override matmul/@ if
>> __array_ufunc__ is set", it seems there is consensus around the idea of
>> making matmul a true gufunc, but matmul can behave differently for
>> different combinations of array and vector:
>> (n,k),(k,m)->(n,m)
>> (n,k),(k) -> (n)
>> (k),(k,m)->(m)
>> Currently there is no way to express that in the ufunc signature. The
>> proposed solution to issue #9029 is to extend the meaning of a signature
>> so "syntax like (n?,k),(k,m?)->(n?,m?) could mean that n and m are
>> optional dimensions; if missing in the input, they're treated as 1, and
>> then dropped from the output" Additionally, there is an open pull
>> request #5015 "Add frozen dimensions to gufunc signatures" to allow
>> signatures like '(3),(3)->(3)'.
> How much harder would it be to implement multiple-dispatch for gufunc
> signatures, instead of modifying the signature to include `?` ?
> There was some discussion of this last year:
> http://numpy-discussion.10968.n7.nabble.com/Changes-to-generalized-ufunc-core-dimension-checking-tp42618p42638.html
> That sounded like a clean solution to me, although I'm a bit ignorant of
> the gufunc internals and the compatibility constraints.
> I assume gufuncs already have code to match the signature to the array
> dims, so it sounds fairly straightforward (I say without looking at any
> code) to do this in a loop over alternate signatures until one works.
> Allan
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
I will take a look at multiple-dispatch for gufuncs.
The discussion also suggests using an axis kwarg when calling a gufunc 
for which there is PR #1108 (https://github.com/numpy/numpy/pull/11018) 


More information about the NumPy-Discussion mailing list