Stefan, I just read through your proposed API. In general it seems reasonable but Luke, Gilbert and I spoke last night on irc (logs: http://colabti.org/irclogger/irclogger_log/sympy?date=2013-06-12) about how to deal with immutability/mutability, subclassing from Basic/Expr, and garbage in/out. The mechanics module has a unique use case where we have to track the same tree of direction cosine matrices for each reference frame involved. Currently we hide this tree on the ReferenceFrame objects and it is a mutable entity. If you add another ReferenceFrame to the tree then other ReferenceFrames need to know about this addition direction cosine matrix definition. For example, in your API, when you use cart_A after you've created cart_B it should reflect that it is rotated with respect to cart_B. As it stands, this wouldn't happen if the frames are immutable. You could imagine having this tree held in your world object but it would also need to be mutable.
I think we, @mechanics, will be fine with most of what you all proposed if we can clearly see that ReferenceFrame (plus velocities, accelerations) will be properly tracked. Our module's cornerstone are these trees that relate reference frames together. Some summary from our conversation: 1. We're fine with immutability and subclassing from Basic if there is a mechanism in place that can handle reference frame relationships correctly and accurately. 2. We're more found of garbage in, throw an error for funny things like vec * vec or scalar + vec. Seems like you have that in your api proposal. Jason moorepants.info +01 530-601-9791 On Wed, Jun 12, 2013 at 8:35 AM, Prasoon Shukla <[email protected]>wrote: > > > On Wednesday, June 12, 2013 7:52:34 PM UTC+5:30, Stefan Krastanov wrote: >> >> > For the mutability issue : Just as Aaron suggested, we do really need >> the >> > objects to be mutable. Doing something as >> >> If I understand correctly, Aaron's main point was that mutability is >> useful only in certain cases and I do not think that the current >> module requires it. Most of the arguments in favor of mutability were >> about how to relate two reference frames (both static translation and >> orientation as well as relative velocity and angular velocity). I >> think that the example I provided addresses these issue and mutability >> is not necessary. >> > > Oh! I'm really sorry :P I meant > > ... we do *not* really need the objects to be mutable. Doing something > as .... > > Little typo, big confusion :) > > -- > 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?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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
