[Numpy-discussion] @ operator
Pauli Virtanen
pav at iki.fi
Wed Sep 10 12:52:16 EDT 2014
09.09.2014, 22:52, Charles R Harris kirjoitti:
> 1. Should the operator accept array_like for one of the arguments?
> 2. Does it need to handle __numpy_ufunc__, or will
> __array_priority__ serve?
I think the __matmul__ operator implementation should follow that of
__mul__.
[clip]
> 3. Do we want PyArray_Matmul in the numpy API?
> 4. Should a matmul function be supplied by the multiarray module?
>
> If 3 and 4 are wanted, should they use the __numpy_ufunc__ machinery, or
> will __array_priority__ serve?
dot() function deals with __numpy_ufunc__, and the matmul() function
should behave similarly.
It seems dot() uses __array_priority__ for selection of output return
subclass, so matmul() probably needs do the same thing.
> Note that the type number operators, __add__ and such, currently use
> __numpy_ufunc__ in combination with __array_priority__, this in addition to
> the fact that they are by default using ufuncs that do the same. I'd rather
> that the __*__ operators simply rely on __array_priority__.
The whole business of __array_priority__ and __numpy_ufunc__ in the
binary ops is solely about when __<op>__ should yield the execution to
__r<op>__ of the other object.
The rule of operation currently is: "__rmul__ before __numpy_ufunc__"
If you remove the __numpy_ufunc__ handling, it becomes: "__rmul__ before
__numpy_ufunc__, except if array_priority happens to be smaller than
that of the other class and your class is not an ndarray subclass".
The following binops also do not IIRC respect __array_priority__ in
preferring right-hand operand:
- in-place operations
- comparisons
One question here is whether it's possible to change the behavior of
__array_priority__ here at all, or whether changes are possible only in
the context of adding new attributes telling Numpy what to do.
--
Pauli Virtanen
More information about the NumPy-Discussion
mailing list