I think I’m -1 on this - this just makes things harder on the implementers of _array_ufunc__ who now might have to work out which signature matches. I’d prefer the solution where np.matmul is a wrapper around one of three gufuncs (or maybe just around one with axis insertion) - this is similar to how np.linalg already works. Eric ​ On Mon, 30 Apr 2018 at 14:34 Stephan Hoyer wrote:

On Sun, Apr 29, 2018 at 2:48 AM Matti Picus wrote:

...

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"

I agree that this is an elegant fix for matmul, but are there other use-cases for "optional dimensions" in gufuncs?

It feels a little wrong to add gufunc features if we can only think of one function that can use them. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

On 01/05/18 00:38, Eric Wieser wrote:

I think I’m -1 on this - this just makes things harder on the implementers of |_array_ufunc__| who now might have to work out which signature matches. I’d prefer the solution where |np.matmul| is a wrapper around one of three gufuncs (or maybe just around one with axis insertion) - this is similar to how np.linalg already works.

Eric

​

On Mon, 30 Apr 2018 at 14:34 Stephan Hoyer mailto:shoyer@gmail.com> wrote:

On Sun, Apr 29, 2018 at 2:48 AM Matti Picus mailto:matti.picus@gmail.com> wrote:

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"

I agree that this is an elegant fix for matmul, but are there other use-cases for "optional dimensions" in gufuncs?

It feels a little wrong to add gufunc features if we can only think of one function that can use them. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org mailto:NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

I will try to prototype this solution and put it up for comment, alongside the multi-signature one. Matti

There is always the option of any downstream object overriding matmul, and I fail to see which objects won't have a shape. - Hameer On 01/05/2018 at 21:08, Marten wrote: Just for completeness: there are *four* gufuncs (matmat, matvec, vecmat, and vecvec). I remain torn about the best way forward. The main argument against using them inside matmul is that in order to decide which of the four to use, matmul has to have access to the `shape` of the arguments. This meants that means that `__array_ufunc__` cannot be used to override `matmul` (or `@`) for any object which does not have a shape.

From that perspective, multiple signatures is definitely a more elegant solution.

An advantage of the separate solution is that they are useful independently of whether they are used internally in `matmul`; though, then again, with a multi-signature matmul, these would be trivially created as convenience functions. -- Marten _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

On Wed, May 2, 2018 at 8:39 AM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:

I think we should not decide too readily on what is "reasonable" to expect for a ufunc input.

I agree strongly with this. I can think of a couple of other use-cases off hand: - xarray.Dataset is a dict-like container of multiple arrays. Matrix-multiplication with a numpy array could make sense (just map over all the contained arrays), but xarray.Dataset itself is not an array and thus does not define shape. - tensorflow.Tensor can have a dynamic shape that is only known when computation is explicitly run, not when computation is defined in Python. The problem is even bigger for np.matmul because NumPy also wants to use the same logic for overriding @, and Python's built-in operators definitely should not have such restrictions.

Hi Matti, In the original implementation of what was then __numpy_ufunc__, we had overrides for both `np.dot` and `np.matmul` that worked exactly as your option (2), but we decided in the end that those really are not true ufuncs and we should not include ufunc mimics in the mix as someone using `__array_ufunc__` should be able to count on being passed a ufunc, including all its properties. Perhaps this needs revisiting, and we should have some UFuncABC... But my own feeling remains that matmul is close enough to a (set of) gufunc that making it fit the gufunc mold is the way to go... All the best, Marten

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-cor...

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 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) discussion).

Matti