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 `
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
On Wed, May 2, 2018 at 8:39 AM Marten van Kerkwijk <
m.h.vankerkw...@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-l
On Wed, May 2, 2018 at 6:24 AM, Hameer Abbasi 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,
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 forwar
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 me
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
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
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
differen
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:
>
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
h
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
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 "pseudo-ufuncs" that just add a 1 in the right
place and call `matmul`...
-- Mart
Hi Matti,
This sounds great. For completeness, you omitted the vector-vector
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
___
NumPy-Discussion mailing
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)->
15 matches
Mail list logo
