[Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

Marten van Kerkwijk m.h.vankerkwijk at gmail.com
Tue Jun 26 14:25:25 EDT 2018


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 <shoyer at gmail.com> wrote:

> 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.
>
>>>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180626/0c38a3db/attachment-0001.html>


More information about the NumPy-Discussion mailing list