On Wed, Jul 13, 2011 at 1:19 PM, 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? > > 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.
Well, the dispatch solution only works for op.whatever, but as we know, reduce(op.whatever, list_of_args) is asymptotically less efficient than Whatever(*list_of_args). Actually, half of the problem isn't so much making Add/Mul/etc. work with dispatch rules, but making it *efficiently* work with dispatch rules. Aaron Meurer > > -- > 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. > > -- 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.
