[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