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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
