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
