I see. This makes sense. I dislike the creation of a new class just for the sake of adding helper methods (it mixes functions and data in an unaesthetic way), but this is just my preference, so I will not raise an objection if this is what you prefer.
The big issue now is how well will this work with mechanics. I am against making big compromises in the future architecture in order to accommodate mechanics, but a well working interface must be created. While RefFrames will have to be immutable to be used within Sympy trees (or at least have consistent hash and eq as is done with the mutable coordSystems from diffgeom) you might want to think about some nice (mutable) tree of RefFrames structure that will accomodate mechanics. On 14 June 2013 12:14, Prasoon Shukla <prasoon92.i...@gmail.com> wrote: > >> Any additional methods that are provided will _not work_ if they do >> not have access to the RefFrame objects (in order to know how to >> transform between coordinates). Your proposal does not explain how >> these RefFrame objects will be accessed. > > > But they do. > > I'll try to explain the structure one more time. > Basic->Expr->Vector > > Every Vector has an attribute, `ref_frame`, that specifies the RefFrame > object that we are using for that vector. (Also,Vector objects are just > basis vectors) > > Now, let us say we have a vector field like this: > > v = x * e_x + y * e_y + z * e_z > > Without the VectAdd class, v is just an Add and we would have none of the > methods we need for operating on vectors. Instead, if we have v as a VectAdd > object, we can extend the Add class to provide methods that are required on > vectors. > > Initially, when we weren't following the basis vector based approach, v > would have been a Vector object. In that case, we would have had these > methods defined in the Vector class. But since we are following the approach > where a Vector is just a basis vector, therefore we need something to deal > with vector fields that are not instances of Vector. Hence the requirement > for these two classes. > > Here's the hierarchy: > Basic->Expr->Add->VectAdd > > Basic->Expr->Mul->VectMul > > I hope this clarifies the issue. Any more problems? > > -- > 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. > 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. For more options, visit https://groups.google.com/groups/opt_out.
