Am 09.03.2014 03:22, schrieb [email protected]:
I'd really appreciate comments and feedback from you guys -- esp. since sympy is probably the most prominent library that *doesn't* currently follow the numpy convention of using * for elementwise multiplication. Does this seem like something that would benefit you?
Not really. SymPy already needs to overload all the standard operators to more closely follow mathematical conventions, while programmer conventions take a back seat. For that reason, Matrix * Matrix is matrix multiplication in SymPy, not elementwise multiplication - we have a Matrix type anyway, and we don't need to worry how the operator extends into arbitrary collections, so all the reasons for an elementwise multiplication don't apply.
Also, from a mathematician's point of view, that's four(!) new operators. This looks like going overboard to resolve a rather specific use case. Yeah, for us, the "it's the one operator Python needs" holds no water at all. We want circumfix Bra-Ket (i.e. <v| and |w>), we want nabla, we want cross product and scalar product, we want to be able to write |x| for the absolute value, etc. pp. So for SymPy, adding just one operator is solving the least of our problems, and adding a different one that covers a semantics we already have isn't solving any problems at all.
That said, if you add new operators, we'll simply implement @ as a synonym to * for our Matrix classes, so we don't oppose either.
Now personally, from a language designer's point of view, while I agree that matrix multiplication is an important operation, I disagree it's worth adding it. Python already has a multitude of operators, it's already hard to memorize the precedences by heart, and adding yet another operator is going to make things worse, not better. (The problem multiplies if you work with multiple programming languages; it's already a real problem for me.) Also, I'm missing a serious(!) discussion of the downsides of adding @ in the PEP. Reading it left a taste of "yeah but did they think about any potential problems and thought about ways to address them". From my perspective, the way to go isn't adding yet another operator, it's adding user-defined operators to Python. Yes you'd have to provide good answers to the BDFL's concerns, but I consider that a Good Thing :-)
Just my 2c. Regards, Jo -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/531C1D52.2040008%40durchholz.org. For more options, visit https://groups.google.com/d/optout.
