[Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs
Stephan Hoyer
shoyer at gmail.com
Fri Jun 15 14:17:09 EDT 2018
On Mon, Jun 11, 2018 at 11:59 PM Eric Wieser <wieser.eric+numpy at 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- at -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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180615/c5b747f8/attachment.html>
More information about the NumPy-Discussion
mailing list