On Mon, Jun 11, 2018 at 11:59 PM Eric Wieser <wieser.eric+nu...@gmail.com> wrote:
> I don’t understand your alternative here. If we overload np.matmul using > *array_function*, then it would not use *ether* of these options for > writing the operation in terms of other gufuncs. It would simply look for > an *array_function* attribute, and call that method instead. > > Let me explain that suggestion a little more clearly. > > 1. There’d be a linalg.matmul2d that performs the real matrix case, > which would be easy to make as a ufunc right now. > 2. __matmul__ and __rmatmul__ would just call np.matmul, as they > currently do (for consistency between np.matmul and operator.matmul, > needed in python pre-@-operator) > 3. np.matmul would be implemented as: > > @do_array_function_overridesdef matmul(a, b): > if a.ndim != 1 and b.ndim != 1: > return matmul2d(a, b) > elif a.ndim != 1: > return matmul2d(a, b[:,None])[...,0] > elif b.ndim != 1: > return matmul2d(a[None,:], b) > else: > # this one probably deserves its own ufunf > return matmul2d(a[None,:], b[:,None])[0,0] > > 4. Quantity can just override __array_ufunc__ as with any other ufunc > 5. DataArray, knowing the above doesn’t work, would implement > something like > > @matmul.register_array_function(DataArray)def __array_function__(a, b): > if a.ndim != 1 and b.ndim != 1: > return matmul2d(a, b) > else: > # either: > # - add/remove dummy dimensions in a dataarray-specific way > # - downcast to ndarray and do the dimension juggling there > > > Advantages of this approach: > > - > > Neither the ufunc machinery, nor __array_ufunc__, nor the inner loop, > need to know about optional dimensions. > - > > We get a matmul2d ufunc, that all subclasses support out of the box if > they support matmul > > Eric > OK, this sounds pretty reasonable to me -- assuming we manage to figure out the __array_function__ proposal! There's one additional ingredient we would need to make this work well: some way to guarantee that "ndim" and indexing operations are available without casting to a base numpy array. For now, np.asanyarray() would probably suffice, but that isn't quite right (e.g., this would fail for np.matrix). In the long term, I think we need a new coercion protocol for "duck" arrays. Nathaniel Smith and I started writing a NEP on this, but it isn't quite ready yet. > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
