[Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power
Nick Coghlan
ncoghlan at gmail.com
Sat Mar 15 16:48:44 CET 2014
On 16 March 2014 01:22, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 16 Mar 2014 02:11:43 +1100
> Steven D'Aprano <steve at pearwood.info> wrote:
>> > The possible reason given in the PEP is very weak and amounts to
>> > premature optimization:
>>
>> I don't think it's premature optimization. Sometimes we do know ahead of
>> time that a calculation done one way will be faster than doing it
>> another way: you don't have to "try it and see" to realise that
>> repeatedly adding strings in a for-loop can be O(N**2) versus O(N) for
>> using str.join().
>
> It's premature optimization because the PEP is proposing to enforce it
> at the language level. We didn't change *the language* so that "str +="
> allows for O(N) repeated concatenation; instead we tell people that
> "".join() should be used for repeated concatenation. Why would our
> course of action be different for matrix multiplication?
That's why Guido's request was for the numeric community to go back
and try to come up with a better rationale one way or the other for
that question - he wanted to make it clear to them that right
associativity *was* potentially acceptable, so they should seriously
consider the question and make the case for right associativity if
they decided they really wanted it, rather than assume that we would
reject the idea out of hand. Left associativity still remains the
default, and this isn't the right list to argue about the choice (as
most of the relevant people aren't here). If the numeric computing
community decide they *do* want right associativity and add that to
the PEP, *then* Guido will need to make the call as to whether or not
he considers their rationale for requesting it convincing (and we will
have the opportunity to chime in with our own perspectives to help him
make up his mind).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list