On Wed, Jul 13, 2011 at 11:19 AM, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le mercredi 13 juillet 2011 à 10:51 -0700, Brian Granger a écrit : >> Matthew, >> >> Arron has provided a fantastic summary of the issues involve. The >> summary is that even if you subclass Add/Mul/Pow, sympy will end up >> creating expressions that don't use your subclasses everywhere. This >> can't be fixed without changing the core, which is outside the scope >> of your project. I know I sound like a broken record, but you should >> resist the temptation to define your own Add/Mul/Pow classes. > > I'm not convinced. What other solution is there?
For now just don't do it. The quantum stuff is equally complicated as the matrix symbols stuff (in fact from a mathematical perspective, they are fomally equivalent) and we are surviving just fine without it. Last summer we started out by subclassing Add/Mul/Pow for the quantum stuff. For weeks we kept finding things that were broken. It was horrible and we realized that i) we would end up rewriting much of sympy and 2) it would still be fundamentally broken. Once we gave up on that are just used sympy Mul/Add/Pow we started to move 10 times faster and had very few problems. We did have to give up on our grand visions of doing custom logic in Mul/Add/Pow, but we have moved that logic into standalone functions. Those functions are quite simple though and work just great. > Also, creating Add/Mul/Pow subclasses looks like the obvious way of > extending sympy, so we want to make it work at some point. Creating > MatrixAdd, etc. will help a lot with that by highlighting all the places > where we assume things like a + b == Add(a, b). So if Matthew thinks he > can make it work without too much pain, compared to the alternatives, > then I think he should go for it. It is not at all obvious to me that the model should be that Add/Mul/Pow subclasses are encouraged. I think a much better approach would be closer to what Mathematica has, where objects can define rules that are applied when the objects are multiplied. IOW, Mul/Add/Pow themselves should have extension APIs, but those extension APIs should not be handled through subclassing. But again, this is a very difficult problem and it is not clear to me what the solution is. In either case, I stlll feel it is beyond the scope of the current work. Cheers, Brian > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgran...@calpoly.edu and elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
