>> Also, Gilbert and I had a small question. How do you plan to implement >> expression of Vectors in different frames? Also, the relationships between >> the frames? Could you give an API and the basic idea of how those methods >> will work? >> The main concern the mechanics group has, is the modeling of relationships >> among frames themselves, and those with vectors. Clearing up this part would >> make things much clearer. > > > Again, I really do not see what is so confusing. I'll try to be clear this > time.
Prasoon, in this case I do not think the issue is someones confusion with what the suggestion is. `mechanics` has a very specific goal and it is optimized for it - easily traversing a very deep tree of relations between reference systems. While indeed what you have suggested is sufficient to make such traversals possible, one should be wary of whether it will work _well_ with deep trees. One issue that you will meet very soon is that expressing cart->spherical->cart transformation will often fail to symplify to an identity transformation (a lot of information must be specified for stuff like cos(acos(cos(a))) to return cos or for sqrt(x)*sqrt(1/x) to return 1). While the above is probably not the exact concern of Gilbert and the others in the mechanics team I am sure they have similar worries. And do not forget that mechanics is fast at the moment. With your methodology it might be hard to keep up with its performance. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
