I'm only skimming over this thread but I noticed that the Basic/Expr question came up.
MatrixExpressions used to inherit from Expr for exactly the reasons Stefan said (lots of things work out of the box). This was great for startup but eventually became a major pain. At some point I rewrote MatrixExpressions to inherit from Basic instead and made my own MatMul/MatAdd classes. Development has been much smoother since then. My recommendation is to inherit from Basic and make your own Add/Mul classes and your own _eval_simplify etc... methods On Tue, Jun 11, 2013 at 7:49 AM, Sachin Joglekar <srjoglekar...@gmail.com>wrote: > @Prasoon, Vector + Vector is fine. What about vector * vector or scalar + > vector or any other such nonsense operation? If you are going to subclass > from Basic, this can be done with handling of the operators as I have > already pointed out. But how we will do this without operator overloading > in case of Expr subclassing is unclear to me. +1 for subclassing from > Basic. May involve redefining certain functions, but I think thats > essential. > > In any case, I agree about coming to a consensus soon to avoid delay. > > > On Tue, Jun 11, 2013 at 4:56 PM, Prasoon Shukla > <prasoon92.i...@gmail.com>wrote: > >> Let us get some things clear here. Vector is going to be subclassed from >> Basic. Also, after seeing the discussions/problems above, Vector + Vector >> will give an Add on which we can call something akin to a .doit() to result >> in a Vector. I do not see any problems with this approach. >> >> Next, reference frames. First thing is the distinction between RefFrame >> class and CoordSys class. Stefan has pointed out that there is no need to >> implement the classes differently. Okay, then we will have just one, * >> immutable,* CoordSys class. The parameters required for intialization of >> kinematic parameters will have to be provided when declaring the coordinate >> system. New CoordSys object will result from methods like rotate, orient >> etc. >> >> With these suggestions, I do not think that there should be any more >> structural issues. If there are any more of these issues, please mention >> them here now and please mention them as early as possible. >> >> These changes are justified, I hope, because this module has to play nice >> with the rest of SymPy. >> >> I just feel that we are getting stuck with and spending too much time on >> things that we shouldn't be taking this much time. Therefore, I request >> again to all parties involved : Please voice your views/problems with these >> structural changes suggested so that we can move ahead with things. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "sympy" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/sympy/t-Je0beTIIU/unsubscribe?hl=en-US. >> To unsubscribe from this group and all its topics, send an email to >> sympy+unsubscr...@googlegroups.com. >> >> To post to this group, send email to sympy@googlegroups.com. >> Visit this group at http://groups.google.com/group/sympy?hl=en-US. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy?hl=en-US. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
