[Numpy-discussion] @ operator

Charles R Harris charlesr.harris at gmail.com
Wed Sep 10 16:53:22 EDT 2014


On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen <pav at iki.fi> wrote:

> 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.
>
>
I was tempted to make it a generalized ufunc, which would take care of a
lot of things, but there is a lot of overhead in those functions. Sounds
like the easiest thing is to make it similar to dot, although having an
inplace versions complicates the type selection a bit.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140910/3c12f7a3/attachment.html>


More information about the NumPy-Discussion mailing list