

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)'.
I would like extending ufunc signature handling to implement both these
ideas, in a way that would be backwardlycompatible with the publicly
exposed PyUFuncObject. PyUFunc_FromFuncAndDataAndSignature is used to
allocate and initialize a PyUFuncObject, are there downstream projects
that allocate their own PyUFuncObject not via
PyUFunc_FromFuncAndDataAndSignature? If so, we could use one of the
"reserved" fields, or extend the meaning of the "identity" field to
allow version detection. Any thoughts?
Any other thoughts about extending the signature syntax?
Thanks,
Matti
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


Hi Matti,
This sounds great. For completeness, you omitted the vectorvector
case for matmul '(k),(k)>()'  but the suggested new signature for
`matmul` would cover that case as well, so not a problem.
All the best,
Marten
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


I thought a bit further about this proposal: a disadvantage for matmul
specifically is that is does not solve the need for `matvec`,
`vecmat`, and `vecvec` gufuncs. That said, it might make sense to
implement those as "pseudoufuncs" that just add a 1 in the right
place and call `matmul`...
 Marten
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 usecases 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.
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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
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 usecases 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.
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 multipledispatch for gufunc
signatures, instead of modifying the signature to include `?` ?
There was some discussion of this last year:
http://numpydiscussion.10968.n7.nabble.com/Changestogeneralizedufunccoredimensioncheckingtp42618p42638.htmlThat 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
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 multipledispatch for gufunc
> signatures, instead of modifying the signature to include `?` ?
>
> There was some discussion of this last year:
>
> http://numpydiscussion.10968.n7.nabble.com/Changestogeneralizedufunccoredimensioncheckingtp42618p42638.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
> _______________________________________________
> NumPyDiscussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpydiscussionI will take a look at multipledispatch 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
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


I agree with Eric here. As one of the users of __array_ufunc__, I'd
much rather have three separate gufuncs or a single one with axis
insertion and removal. On 30/04/2018 at 23:38, Eric 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 < [hidden email]> wrote: On Sun, Apr 29, 2018 at
2:48 AM Matti Picus < [hidden email]> 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 usecases 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.
_______________________________________________ NumPyDiscussion
mailing list [hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 < [hidden email]
> <mailto: [hidden email]>> wrote:
>
> On Sun, Apr 29, 2018 at 2:48 AM Matti Picus < [hidden email]
> <mailto: [hidden email]>> 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 usecases 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.
> _______________________________________________
> NumPyDiscussion mailing list
> [hidden email] <mailto: [hidden email]>
> https://mail.python.org/mailman/listinfo/numpydiscussion>
>
>
> _______________________________________________
> NumPyDiscussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpydiscussionI will try to prototype this solution and put it up for comment,
alongside the multisignature one.
Matti
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 multisignature matmul, these would be trivially
created as convenience functions.
 Marten
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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 multisignature matmul, these would be trivially created as convenience functions.
 Marten
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


On Wed, May 2, 2018 at 6:24 AM, Hameer Abbasi < [hidden email]> wrote:
> There is always the option of any downstream object overriding matmul, and I
> fail to see which objects won't have a shape.  Hameer
I think we should not decide too readily on what is "reasonable" to
expect for a ufunc input. For instance, I'm currently writing a
chainedufunc class which uses __array_ufunc__ to help make a chain
(something like `chained_ufunc = np.sin(np.multiply(Input(),
Input()))`). Here, my `Input` class defines `__array_ufunc__` but
definitely does not have a shape, and I would like to be able to
override `np.matmul` just like every other ufunc.
 Marten
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


On Wed, May 2, 2018 at 8:39 AM Marten van Kerkwijk < [hidden email]> 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 usecases off hand:  xarray.Dataset is a dictlike container of multiple arrays. Matrixmultiplication 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 builtin operators definitely should not have such restrictions.
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


On 01/05/18 21:08, Marten van Kerkwijk 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 multisignature matmul, these would be trivially
> created as convenience functions.
>
>  Marten
> _______________________________________________
> NumPyDiscussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpydiscussionMy goal is to solve issue #9028, "no way to override matmul/@ if
__array_ufunc__ is set on other". Maybe I am too focused on that, it
seems shape does not come into play here.
Given a call to matmul(self, other) it appears to me that the decision
to commit to self.matmul or to call other.__array_ufunc__("__call__",
self.matmul, ...) is independent of the shapes and needs only nin and nout.
In other words, the implementation of matmul becomes (simplified):
(matmul(self, other) called)>
(use __array_ufunc__ and nin and nout to decide whether to defer to
other's __array_ufunc__ via PyUFunc_CheckOverride which implements NEP13) >
(yes: call other.__array_ufunc__ as for any other ufunc),
(no: call matmul like we currently do, no more __aray__ufunc__
testing needed)
So the two avenues I am trying are
1) make matmul a gufunc and then it will automatically use the
__array_ufunc__ machinery without any added changes, but this requires
expanding the meaning of a signature to allow dispatch
2) generalize the __array_ufunc__ machinery to handle some kind of
wrapped function, the wrapper knows about nin and nout and calls
PyUFunc_CheckOverride, which would allow matmul to work unchanged and
might support other functions as well.
The issue of whether matmat, vecmat, matvec, and vecvec are functions,
gufuncs accessible from userland, or not defined at all is secondary to
the current issue of overriding matmul , we can decide that in the future.
If we do create ufuncs for these variants, calling a.vecmat(other) for
instance will still resolve to other's __array_ufunc__ without needing
to explore other's shape.
I probably misunderstood what you were driving at because I am so
focused on this particular issue.
Matti
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion


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
_______________________________________________
NumPyDiscussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpydiscussion

