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

Antony Lee antony.lee at berkeley.edu
Fri Mar 14 19:41:11 CET 2014


A simple suggestion: what about defining the special methods as __at__,
__rat__, __iat__ (@) and __atat__, __ratat__, __iatat__ (@@)?  This make
the operator more "neutral" -- it make it sound less "wrong" to overload it
for something else that matrix multiplication (which is certainly an
important topic, but even though I use numpy quite a lot, I don't actually
use it at all for linear algebra (in fact I use elementwise multiplications
much more often) -- so counting imports of numpy is a somewhat biaised
metric for counting users of matrix multiplication).

Antony


2014-03-14 10:53 GMT-07:00 Guido van Rossum <guido at python.org>:

> 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.)
>
> - 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.
>
> - 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.
>
> - 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.
>
> Once we've decided on associativity and @@, I'm ready to accept.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas 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/ea723753/attachment.html>


More information about the Python-ideas mailing list