|New PEP for infix operator||Aaron Meurer||2/25/14 8:31 AM|
Some people on this list might be interested in this. Some folks are
giving another shot at writing a PEP to add a new operator to Python
for matrix multiplication. The discussion is at
Those of you who work with tensors may want to have a look as well.
There is talk to extending the operator to higher dimensional arrays,
but I feel that the discussion would be easier if it were formalized
into the language of tensor contractions.
|unk...@googlegroups.com||2/25/14 9:27 AM||<This message has been deleted.>|
|Re: New PEP for infix operator||Sergey Kirpichev||2/25/14 3:02 PM|
On Tuesday, February 25, 2014 8:31:02 PM UTC+4, Aaron Meurer wrote:Some people on this list might be interested in this. Some folks are
Really bad idea. It's better to have an ability to define arbitrary
infix operator (like Haskell, for example).
|Re: [sympy] Re: New PEP for infix operator||Christophe Bal||2/25/14 3:49 PM|
Can you give a little example showing how to define an infix operator in Haskell ?
|Re: [sympy] Re: New PEP for infix operator||Sergey Kirpichev||2/25/14 4:02 PM|
|Re: [sympy] Re: New PEP for infix operator||Aaron Meurer||2/25/14 4:10 PM|
Previous PEPs have tried this and failed. This PEP is an attempt at a
compromise that suits the community's needs but still has potential to
be accepted by the BDFL.
|Re: [sympy] Re: New PEP for infix operator||Christophe Bal||2/26/14 2:35 AM|
I'm not sure but it seems that Ruby syntax can be a solution. Here is an example.
Instead of the method __add__(self, ...) , we could use the method +(self, ...).
The only change will be to manage dynamical infix lexer for the Python parser.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Lq2v3sQb_KAoT%2BCWetfaSh4LPGOM0J%2BpXpLhHtb8XChA%40mail.gmail.com.
|Re: [sympy] Re: New PEP for infix operator||Sergey Kirpichev||2/26/14 4:22 AM|
On Wed, Feb 26, 2014 at 2:35 PM, Christophe Bal <proj...@gmail.com> wrote:Ruby can't do this as flexible as Haskell. AFAIK, only few predefined
operators can be used.
How about __radd__?
|Re: [sympy] Re: New PEP for infix operator||Joachim Durchholz||2/26/14 4:57 AM|
Am 26.02.2014 00:02, schrieb Sergey Kirpichev:> Really bad idea.
What's bad about it?
In general, yes, but you definitely need to weigh it against several issues:
- Dealing with fixity, i.e. infix, prefix, postfix. We'd want all three
if we're to stick closely to mathematical notation.
- How much parenthesizing do you want? If you wish to allow prefix and
postfix operators at the same precedence level, things can get
ambiguous: if % is both prefix or postfix, % x % could be either
(% x) % or % (x %). This might be undesirable if the language has no
preexisting rule of that kind (ever additional rule means a steeper
- How do you distinguish between operators and functions?
- How do you keep precedence levels under control? In particular, how do
you make sure that programmers know what precedence levels apply if they
read code that makes heavy use of user-defined operators?
> (like Haskell, for example).
In Haskell, every function is a prefix operator (despite appearances,
there is no such thing as a multi-parameter function).
This simplifies syntax tremendously (semantics, too, but that's
irrelevant here), which means that arbitrary operators fit in easily.
Unfortunately, this isn't necessarily easy in other languages.
Given all these constraints and caveats, I find it hard to judge any
proposal as good idea or bad idea. You always have to look at the design
goals (which may or may not match SymPy's), and at the existing language.
|Re: [sympy] Re: New PEP for infix operator||Sergey Kirpichev||2/26/14 7:41 AM|
On Wed, Feb 26, 2014 at 01:57:03PM +0100, Joachim Durchholz wrote:Because it turn python to be a DSL for numeric computations.
Yes, and I think it's not new idea and it was discussed already
in mail threads for previous PEP.
|Re: [sympy] Re: New PEP for infix operator||Aaron Meurer||2/26/14 11:49 AM|
On Wed, Feb 26, 2014 at 9:41 AM, Sergey B KirpichevHow is that a bad thing? Python is already used heavily for numeric
computations. Adding this one thing would simplify so much of that
> --> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/20140226154104.GA10731%40darkstar.order.hcn-strela.ru.
|Re: [sympy] Re: New PEP for infix operator||Matthew||2/26/14 12:05 PM|
This seems like an odd forum for this conversation. I wonder if there is a discussion on this topic that reaches more of the affected community.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L8pu7ejjqkWUbA%2By%2BjUkg01PrdyjTbHF4xVaRa1McyoA%40mail.gmail.com.
|Re: [sympy] Re: New PEP for infix operator||Joachim Durchholz||2/26/14 12:37 PM|
Am 26.02.2014 21:05, schrieb Matthew Rocklin:The PEP proposes to introduce @ and @@ as new operators.
Extending the language with arbitrary operators is outside the PEP's
scope (for better or for worse), so it's not appropriate for Sergej's
It may be that SymPy can make a push for that if we find a consensus, so
the discussion here does have merit.
(Unfortunately, the PEP doesn't clearly list the reasons why Sergej's
approach was thrown out. Maybe a writeup is in order.)
|Re: [sympy] Re: New PEP for infix operator||Aaron Meurer||2/26/14 5:04 PM|
Yes, it's on the pull request that I linked to. But note that there is
a lot of history with this idea, so you should probably educate
yourself before jumping right in and claiming you know how to make
Python a better place.
|Re: [sympy] Re: New PEP for infix operator||Sergey Kirpichev||2/27/14 4:59 AM|
and some arguments against matrix mul as well, e.g.:
It's good for this specific domain, but bad for the Python in general,
as it is not a DSL.
btw, here is a discussion of the possibility to have generic infix ops (the whole thread):
|Re: [sympy] Re: New PEP for infix operator||Joachim Durchholz||2/27/14 9:45 AM|
(a) The idea has been rejected by the BDFL, so the question is what the
reasons for that were and whether a new proposal can eliminate them.
(BTW it's entirely possible that the current PEP will be rejected as well.)
(b) There's the question of what we as SymPy might want out of Python's
operator system. What issues do we have, what's making our life
miserable? (I can guess there is, it would be nice to have the
established notations for bra and ket, for example.)
To raise our voice in that discussion, it would probably be a good idea
to answer (b) first.
We can probably also shed some light on the @ proponents' claim that
matrix multiplication is the one use case for which adding another
operator is a good idea - I guess we'd disagree, but we should bring
statistics. (From the perspective of SymPy, @ for matrix multiplication
is nonsensical anyway, we do well with * - do we?)
|Re: [sympy] New PEP for infix operator||pr...@goodok.ru||2/27/14 1:42 PM|
Usually (in the one expression) we use only one type of the binary
operator for the multiplication.
And the example in the PEP also use only one operator '@' in some
context without mixing with '*' operator in this expression (for the
S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)
Moreover, I can't imagine easy the example when two types of the binary
operators can be used simultaneously for the same class in one
expression (or even in one block of expressions).
If it is so, then it is possible maintain code and expressions to be
readable with the help of the switching of the context for this "*"
operator. Just use the python's dynamical polymorphism.
Suppose we have a class of the array (class M). See attachment for details.
And we want to use sometimes the elemente-wise product, or sometimes
And we want to write down expressions more readable for both cases
a = M([1, 2, 3])
b = M([5, 7, 11])
c = M([1, 2, 4])
Element wise product:
>>> a * b * c
[5, 28, 132]
# switch to cauchy_product
>>> M.mul_current = M.mul_cauchy_product
>>> a * b * c
[5, 27, 94]
We can do it by switching: M.mul_current = M.mul_cauchy_product
(It is possible to use class method if it have a few methods to be
switched: __rmul__, for example)
Disadvantage of this:
We can forget to switch '*' operator to the default behavior after
usage, or this situation may occur as the result of some exception.
But may be it is possible to combine switching with the "with .. as"
statement. (Some __enter__, __exit__ methods?)
Element wise product:
>>> a * b * c
[5, 28, 132]
>>> with M.use_cauhcy_product() as dummy:
>>> a * b * c
[5, 27, 94]
The last example is not implemented in the attachment. But I don't see
the big problems, expect that "with...as" statement usually uses for the
object's context, not classes.
As my opinion (conclusion) I don't think that PEP for '@' operator is
timely and not even convenient.
|Re: [sympy] New PEP for infix operator||brombo||2/27/14 2:36 PM|
What is wrong with operator overloading in classes and using parenthesis
where you have to due to the operator precedence in python. In the
multivector class I use -
* geometric product
^ exterior (wedge) product
| interior (dot) product
additionally you have to use parenthesis anyway if the operator is not
associative (the, |, dot product is not associative).
|Re: [sympy] New PEP for infix operator||pr...@goodok.ru||2/27/14 4:06 PM|
As I understand you mean examples of
and examples of the processor from the string (without parenthesis) to
I see that many types of products are used simultaneously in one
expression, and it is needed indeed.
May be you want use more ones?
I agreed that in the complex cases the priority of operators, non
associativity is significant.
For operator precedence I can't say anything.
But do not mind to to use parenthesis. If '*' operator, __mul__ well
defined, and parenthesis are used, then constructor of the expression
tree work perfect. (if sympy/core/mul.py:Mul.flatten not reorder the
I just don't see the necessity of the additional "@" operator for
numpy's examples with matrix multiplication.
They justify the use of the operator "@" so that the operator "*" is
busy for element-wise product somewhere outside of the current context.
But in this case (only one type of product is used in some scope) this
problem solved by switching of "*" binary operator. Without introduction
of new "@" operator in Python.
|Re: [sympy] New PEP for infix operator||Aaron Meurer||2/27/14 5:02 PM|
There *is* this in NumPy (which is the main use-case for this PEP):
numpy.matrix. But it causes headaches for everyone who uses it.
> --> https://groups.google.com/d/msgid/sympy/530FB132.8030506%40goodok.ru.
|Re: [sympy] Re: New PEP for infix operator||Joachim Durchholz||2/28/14 1:17 AM|
Am 27.02.2014 13:59, schrieb Sergey Kirpichev:
> btw, here is a discussion of the possibility to have generic infix ops (theI have finally gotten around to read the thread.
It's a waste to time to read that. Lots of ideas being idly discussed by
people who know little about language design and keep arguing from their
personal use cases - which is interesting but only half of the relevant
aspects, the other half is possible interaction with other language
|Re: [sympy] New PEP for infix operator||Joachim Durchholz||2/28/14 1:24 AM|
Am 25.02.2014 17:31, schrieb Aaron Meurer:I think it's irrelevant to SymPy.
It's a proposal to add a predefined @ operator that does matrix
SymPy does not need it - our users haven't exactly been asking for that
SymPy isn't seriously affected by it either. If it should happen to be
accepted into the language, SymPy can easily support it as a synonym for
*, and that's it.
I share Sergey's view that Python should (and probably could) profit
more from user-defined operators.
However, I do not think that the introduction of @ would be a problem,
it would just be enother predefined operator, and Python being Python,
any mechanism for user-defined operators would allow people to redefine
standard operators in subclasses.
So that issue is orthogonal to the introduction of @.
|Re: [sympy] New PEP for infix operator||Aaron Meurer||3/1/14 10:49 AM|
I mostly posted on this list because the author of the PEP wanted some
input from people with knowledge of tensor mathematics, so that the
parts about higher dimensional arrays could be spelled out with a bit
more rigour, and I know that there are a few people in this community
who work a lot with tensors.
> --> https://groups.google.com/d/msgid/sympy/531055E1.9080507%40durchholz.org.
|Re: [sympy] New PEP for infix operator||Ondřej Čertík||3/4/14 11:15 AM|
On Sat, Mar 1, 2014 at 11:49 AM, Aaron Meurer <asme...@gmail.com> wrote:Definitely. I think it would be nice if Python had some operators for that.
But at the same time, I don't think this is such a big deal. In
Fortran or NumPy,
the standard is to use * for elementwise operations, and matmul() resp. dot()
for matrix operations. It works ok in my opinion.