I wonder if it would be best to remove the concept of a reference frame from Prasoon's api design. Then the mechanics and electromagnetics modules will need to implement that on our side on top of the coordinate system classes.
Jason moorepants.info +01 530-601-9791 On Fri, Jun 14, 2013 at 11:19 PM, Gilbert Gede <gilbertg...@gmail.com>wrote: > Yes Stefan, I think you are articulating our concerns well. And while I've > never done the rect/spherical/rect transform, just going back and forth > between rect. frames causes similar issues with trig expressions not > collapsing. > > I'd like to know more about the mutability of diffgeom's CoordSystems > though. From reading the code, it looks like it is accomplished by storing > the mutable information outside of args, and having the parent patch as an > arg to the coordinate system? How robust does this end up being? > > > On Fri, Jun 14, 2013 at 6:59 AM, Stefan Krastanov < > krastanov.ste...@gmail.com> wrote: > >> >> 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 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. > > > -- 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.
