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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion