Hi All, Matti asked me to make a PR accepting my own NEP - https://github.com/numpy/numpy/pull/11429
Any objections? As noted in my earlier summary of the discussion, in principle we can choose to accept only parts, although I think it became clear that the most contentious is also the one arguably most needed, the flexible dimensions for matmul. Moving forward has the advantage that in 1.16 we will actually be able to deal with matmul. All the best, Marten On Fri, Jun 15, 2018 at 2:17 PM, Stephan Hoyer <sho...@gmail.com> wrote: > 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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
