[Numpy-discussion] Matrix multiplication infix operator PEP nearly ready to go

[Nathaniel Smith]

On Thu, Mar 13, 2014 at 1:03 AM, Alan G Isaac <alan.isaac at gmail.com> wrote:
> On 3/12/2014 6:04 PM, Nathaniel Smith wrote:
>>    https://github.com/numpy/numpy/pull/4351
>
> The Semantics section still begins with 0d, then 2d, then 1d, then nd.
> Given the context of the proposal, the order should be:
>
> 2d (the core need expressed in the proposal)
> nd (which generalizes via broadcasting the 2d behavior)
> 1d (special casing)
> 0d (error)

I've just switched it to 2d -> 1d -> 3d+ -> 0d. You're right that 2d
should go first, but IMO 1d should go after it because 2d and 1d are
the two cases that really get used heavily in practice.

> In this context I see one serious problem: is there a NumPy function
> that produces the proposed nd behavior?  If not why not, and
> can it really be sold as a core need if the need to implement
> it has never been pressed to the point of an implementation?

The logic isn't "we have a core need to implement these exact
semantics". It's: "we have a core need for this operator; given that
we are adding an operator we have to figure out exactly what the
semantics should be; we did that and documented it and got consensus
from a bunch of projects on it". I don't think the actual details of
the semantics matter nearly as much as the fact that they exist.

> Unless this behavior is first implemented, the obvious question remains:
> why will `@` not just implement `dot`, for which there is a well
> tested and much used implementation?

Because of the reason above, I'm not sure it will come up (I don't
think python-dev is nearly as familiar with the corner cases of
numpy.dot as we are :-)). But if it does the answer is easy: no-one
ever thought through exactly how `dot` should work in these rare edge
cases, now we did. But we can't just change `dot` quickly, because of
backwards compatibility considerations. `@` is new, there's no
compatibility problem, so we might as well get it right from the
start.

If the behavioural differences between `dot` and `@` were more
controversial then I'd worry more. But the consequences of the 0d
thing are trivial to understand, and in the 3d+ case we're already
shipping dozens of functions that have exactly these broadcasting
semantics.

-n