> 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.
