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 https://github.com/numpy/numpy/pull/4351. 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. Aaron Meurer |

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 | Hello. Can you give a little example showing how to define an infix operator in Haskell ? Christophe -- |

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. Aaron Meurer |

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. class matrix(): 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. Christophe BAL 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 learning curve). - 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 B 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 code. Aaron Meurer
> --> 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 issue anyway. 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. Aaron Meurer > https://groups.google.com/d/msgid/sympy/CAJ8oX-EE_dfcDrAazxLyELo%2B829c%3DpsKo2tiPFqcpaL1B%2BM6ng%40mail.gmail.com. |

Re: [sympy] Re: New PEP for infix operator | Sergey Kirpichev | 2/27/14 4:59 AM |
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): https://mail.python.org/pipermail/python-dev/2008-July/081509.html https://mail.python.org/pipermail/python-dev/2008-July/081537.html |

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 same class): 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. Example: 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 Cauchy product. 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] Cauchy product: # 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] Cauchy product: >>> 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. -- Alexey Gudchenko |

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 - + addition - subtraction * 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
https://github.com/sympy/sympy/tree/master/sympy/galgebra/ga.py https://github.com/sympy/sympy/blob/master/sympy/galgebra/tests/test_ga.py and examples of the processor from the string (without parenthesis) to the expression https://github.com/sympy/sympy/blob/master/sympy/galgebra/precedence.py 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 arguments) 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. https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-matmul-pep.rst 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. -- Alexey Gudchenko |

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. Aaron Meurer > --> 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 features. |

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 multiplication. SymPy does not need it - our users haven't exactly been asking for that specific operator. 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. Aaron Meurer > --> 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. Ondrej |