On Thu, Mar 13, 2014 at 1:03 AM, Alan G Isaac alan.is...@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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
