*>Aaron Meurer* asmeurer at gmail.com

*>Sat Mar 15 01:48:46 CET 2014*

...

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@x, where a is a scalar. Is it more efficient or numerically stable to evaluate that one way or the other?

I'm not a numerical linear algebra expert, but I disagree. If your matrix code needs to be optimized, there's no way around thinking about your specific situation. Optimizing matrix expressions is a tricky problem. http://en.wikipedia.org/wiki/Matrix_chain_multiplication http://en.wikipedia.org/wiki/Matrix_chain_multiplication http://www.youtube.com/watch?v=nVt24G_2VC0 If you want a different order use parenthesis, or build a symbolic expression. I don't think either choice of priority, or associativity will be the right often enough be worth an affront to the "principal of least surprise". Things are nice and clear the way they are.

From the docs http://docs.python.org/3.4/reference/expressions.html#binary-arithmetic-oper... :

"""The binary arithmetic operations have the conventional priority levels... Apart from the power operator[s], there are only two levels, one for multiplicative operators and one for additive operators""" let's keep it like this: Vote P/E/MD/AS not P/E/M/MD/AS. I think that if there is a reason to change is Greg is on the right track: *>Greg Ewing* greg.ewing at canterbury.ac.nz *>Sat Mar 15 12:55:09 CET 2014*

Often,matrix @ vector represents a linear operator acting on an element of a vector space. When you chain them, A @ B @ C @ v conceptually represents acting on v with C, then B, then A.

PS:

*Nathaniel Smith* njs at pobox.com *Fri Mar 14 22:21:12 CET 2014*

The 'matrix @@ -1' notation will probably be a nice win for beginners and other less-sophisticated programmers ...

There's a spot where I like the Facade approach: return an object that only has one method, numpy.solve as __mul__. Make it hard to do badly.

[x.M * y] This is an interesting suggestion! I think it hasn't received full consideration before ... but this might well be the next-best thing to a real operator.

Maybe It is a real operator, it's just spelled ".M*" instead of "@" ;) Thanks for all the work on this Nathaniel. Mark Daoust