[Numpy-discussion] @ operator

[Charles R Harris]

On Wed, Sep 10, 2014 at 2:53 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> 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.
>

Note also that the dot cblas versions are not generally blocked, so the
size of the arrays is limited (and not checked).

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