On Wed, Sep 10, 2014 at 2:53 PM, Charles R Harris <[email protected] > wrote:
> > > On Wed, Sep 10, 2014 at 10:52 AM, Pauli Virtanen <[email protected]> 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
