[Python-ideas] Fwd: [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

Sat Mar 15 01:48:46 CET 2014

On Friday, March 14, 2014 7:46:11 PM UTC-5, Aaron Meurer wrote:

On Friday, March 14, 2014 4:21:12 PM UTC-5, Nathaniel Smith wrote:

> On Fri, Mar 14, 2014 at 5:53 PM, Guido van Rossum <gu... at python.org> 
> wrote: 
>
>> > I have now read the PEP, and I think it's good. I think it's a waste of 
> time 
>
>> > to keep bikeshedding on the choice of operator -- @ is the best 
> compromise. 
>
>> > I do have a few specific notes: 
>
>> > 
>
>> > - Right associativity is not unheard of in Python. E.g. **. If you 
>
>> >   think that for other reasons @ should be right associative, don't 
>
>> >   let Python's tradition stop you. But then you need to decide which 
>
>> >   of * and @ binds more tightly -- e.g. does a*b at c mean a*(b at c) or 
>
>> >   (a*b)@c? And if you choose the latter, it follows that a at b*c means 
>
>> >   a@(b*c) -- is that okay? (And similar examples exist for the other 
>
>> >   choice.) 
>
>>
> Like Robert I have the suspicion that the best option is to make @ 
>
>> right-associative and place it just above (more tightly binding) than 
>
>> *. But I'll poll numpy-discussion and friends and see if anyone has 
> ideas for more objective measures. 
>

I guess a common case would be a*B at x, where a is a scalar.  Is it more 
efficient or numerically stable to evaluate that one way or the other?

Aaron Meurer

> > - Did you consider a duck-typing (is that the word?) attribute? 
>
>> >   E.g. a*b is elementwise multiplication; a.M*b must be used for 
>
>> >   matrix multiplication.  (Your use of .T as "transpose" made me think 
>
>> >   of this.)  Of course the question is, can you get those packages 
>
>> >   that currently use * for matrix multiply to comply? (I don't consider 
>
>> >   this a serious counter-proposal. But you list a bunch of rejected 
>
>> >   alternatives; this could be in that list. 
>
>>
> This is an interesting suggestion! I think it hasn't received full 
>
>> consideration before because the tangle between numpy.ndarray and 
>
>> numpy.matrix means that the most obvious implementation for an 
>
>> ndarray.M attribute would be to return a full-fledged numpy.matrix 
>
>> object... and no-one wants to encourage proliferation of numpy.matrix 
>
>> objects. But returning a tiny special-purpose class that only 
>
>> implements __mul__ would avoid that objection. At that point it's 
>
>> basically a nicer version of the "user-defined infix" '*dot*' operator 
>
>> idea. It has similar problems with needing an unaesthetically magical 
>
>> implementation, producing a proliferation of special classes (one 
>
>> extra one for each array type), requiring an allocation on every call, 
>
>> etc., but this might well be the next-best thing to a real operator. 
>
>>
> All in all, I think we'd rather have a real operator, so if you're 
>
>> happy to go with @ then I won't put lots of effort into finding 
>
>> horrible problems that force us to reject .M ;-), but I'll certainly 
>
>> add it to the PEP in any case. 
>
>>
> > - Is @@ really necessary?  It seems you are adding it mostly because 
>
>> >   it's cute and because of the parallel with **, not because it is 
>
>> >   actually important enough to add new syntax.  And then later you use 
>
>> >   it as an argument for @, which seems a bit circular.  Also, if we 
>
>> >   were to make @ right-associative, the parallel with ** is already 
>
>> >   imperfect. 
>
>>
> @@ hasn't received as much attention as the rest of the proposal, so 
>
>> I'll check in with numpy-discussion etc. on this as well. But my 
>
>> personal feeling is +0 on @@ -- all else being equal, it's nicer to 
>
>> have it than not. Is all else equal? Given the existence of @, the 
>
>> increase in language complexity is small (or arguably negative, since 
>
>> people who know *, **, @ may be surprised to find @@ missing, and have 
>
>> to memorize its non-existence as an extra rule); the opportunity cost 
>
>> is low (given the existence of @ I can't imagine we'll want to use the 
>
>> token @@ for something else later); and @@ will be used in real life, 
>
>> if not as often as @ itself -- 'vec @@ 2' for squared Euclidean length 
>
>> probably won't be too uncommon, 'matrix @@ n' gets used for things 
>
>> like simulating random walks on graphs or other markov chains, and the 
>
>> 'matrix @@ -1' notation will probably be a nice win for beginners and 
>
>> other less-sophisticated programmers who just want to get some 
>
>> computation done in a way that doesn't require them to keep a more 
>
>> complicated mapping between math and code notation in their head or 
>
>> caring about numerical details. I think of @@ being like, say, '%=' -- 
>
>> nothing one would ever add syntax for in isolation, but if designing 
>
>> an overall system of operators then it makes more sense. 
>
>>
> Probably in the end it just comes down to your aesthetic judgement 
>
>> :-). Numeric folk will be fine either way. 
>
>>
> (And I wouldn't consider @@ a *strong* argument for spelling '@' as 
>
>> '@'; it's just mentioned in that section because there aren't really 
>
>> *any* strong arguments for preferring one spelling versus another, we 
>
>> have to make a decision, and so a weak argument is better than 
>
>> nothing. Two useful operators for the complexity cost of one is a good 
>
>> deal? :shrug: Obviously if @@ gets dropped I'll drop that bullet point 
>
>> as well.) 
>
>>
> > - For better counts of usages, perhaps Sourcegraph.com might help?  It 
>
>> >   is a source code query engine that has a Python parser and (limited) 
>
>> >   type inference built in (also separately available as pysonar on 
>
>> >   github IIRC). To be clear, I don't need more numbers to be convinced. 
>
>>
> Oo, that is shiny, thanks for the tip. 
>
>>
> > Once we've decided on associativity and @@, I'm ready to accept. 
>
>>
> Wonderful to hear! Thanks for giving this so much time and attention 
>
>> (on no warning)! 
>
>>
> -n 
>
>>
> -- 
>
>> Nathaniel J. Smith 
>
>> Postdoctoral researcher - Informatics - University of Edinburgh 
>
>> http://vorpus.org 
>
>> _______________________________________________ 
>
>> Python-ideas mailing list 
>
>> Python... at python.org 
>
>> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140314/161d878b/attachment-0001.html>