[Numpy-discussion] How exactly ought 'dot' to work?
Alan G Isaac
alan.isaac at gmail.com
Mon Feb 24 09:31:00 EST 2014
>> 23.02.2014 00:03, Nathaniel Smith kirjoitti:
>>> Currently numpy's 'dot' acts a bit weird for ndim>2 or ndim<1. In
>>> practice this doesn't usually matter much, because these are very
>>> rarely used. But, I would like to nail down the behaviour so we can
>>> say something precise in the matrix multiplication PEP.
> On Sat, Feb 22, 2014 at 7:09 PM, Pauli Virtanen wrote:
>> I'm not sure it's necessary to say much about this in the PEP. It should
>> in my view concentrate on arguing why the new binop is needed in the
>> Python language, and for that, restricting to 2D is good enough IMHO.
>> How exactly Numpy makes use of the capability for > 2-dim arrays is
>> something that should definitely be discussed.
>> But I think this is a problem mainly interesting for Numpy devs, and not
>> for CPython devs.
On 2/24/2014 12:21 AM, Nathaniel Smith wrote:
> I actually disagree strongly. I think it's very important to make
> clear that we have a clear, well thought through, and
> cross-project approach to what @ is supposed to mean
I think Paul is right. We know `@` is supposed to mean
"matrix multiply" when dealing with conformable 2d arrays.
That is the real motivation of the PEP. I cannot see why
the PEP itself would need to go beyond that. The behavior
of `@` in other cases seems a discussion that should go
*much* slower than that of the core of the PEP, which is
to get an operator for matrix multiplication.
Furthermore, I am not able to understand the principles
behind the discussion of how `@` should behave in other cases.
I do not think they are being clearly stated. (I have added
a comment to the PEP asking for clarification.) To be
concrete, if `@` is proposed to behave unlike Mathematica's
`Dot` command, I would hope to hear a very clear
mathematical motivation for this. (Specifically, I do not
understand why `@` would do scalar product.)
Otoh, if the proposal is just that `@` should behave just like
NumPy's `dot` does, that should be simply stated.
More information about the NumPy-Discussion