Prasoon, That option does not work for ReferenceFrame. If I have a ReferenceFrame A, and another ReferenceFrame B, and want to set the angular velocity of B in A as w_1*b_1 + w_2_* b_2 + w_3 * b_3 I need access to the basis vectors of B, which I won't have until after the frame is initialized. Another situation that can occur is the angular velocity being defined as: w_1*b_1 + w_2_* b_2 + w_3 * b_3 + w_k * a_1 I don't see any way around ReferenceFrame being mutable if you want to maintain the same functionality that is in mechanics now. As for having a separate CoordinateSystem and ReferenceFrame: I think it is better to keep these explicit ideas separate if writing two classes doesn't result in much code overlap.
Stefan, regarding your concerns about Vector eating everything up - isn't that how it should be? Once you are dealing with Vectors, won't most operations will result in a Vector? Matthew's suggestion to implement our own VectorAdd/VectorMul seems like it might work though. Also, is there a way to blacklist what functions are allowed to perform on Vectors? On Tue, Jun 11, 2013 at 8:24 AM, Matthew Rocklin <mrock...@gmail.com> wrote: > On Tue, Jun 11, 2013 at 10:14 AM, Stefan Krastanov < > krastanov.ste...@gmail.com> wrote: > >> > What does it mean to factor vectors exactly? >> >> I was thinking about a*unit_vector + b*unit_vector -> (a+b)*unit_vector >> > > My solution was the generic version in sympy/strategies/rl.py. This > particular operation is handled abstractly by glom (which should perhaps be > renamed to factor?) I tried to cover all of the standard operations. The > goal was to not include any generic code in matrices/expressions. Most of > the generic stuff was pushed upstream to rl.py. The hope was that it could > one day serve as generic replacement for the scalar specific stuff in the > Expr codebase. > > >> But as you said there are many others that do not make sense for vectors. >> >> > In contrast the other way has proven to work in physics.quantum. >> They're >> > both reasonable. >> >> And also in diffgeom. >> >> In any case, both of this methodologies seem ok to me (create new >> Add/Mul or reuse Add/Mul), but both of them are not what is proposed >> in general terms on the wiki describing the API (a ScalarField and >> Vector what eagerly eat anything that operates on them, i.e. >> ScalarField+ScalarField -> ScalarField). >> >> Ah, I see. In that case I'll then just say that container classes are > good. They let you describe computations without performing them. You > want this unless you're absolutely sure you know how to handle every > possible input in exactly the right way. Usually this isn't the case. > > >> > >> > >> > On Tue, Jun 11, 2013 at 9:21 AM, Stefan Krastanov >> > <krastanov.ste...@gmail.com> wrote: >> >> >> >> This is also one of the ways to go forward. I personally dislike it >> >> because: >> >> >> >> - A non trivial amount of functionality needs reimplementation >> >> (flatten for instance) >> >> - We do not have "standard correct way" to interface with functions >> >> like factor, symplify, had, get, atoms, etc, so it is hard to be sure >> >> that you have implemented everything >> >> - As a personal preference, I actually like "garbage in - garbage out" >> >> >> >> But this way has been proven to work in matrix expressions and is also >> >> used in Pernici's tensor module, so I am not against it. >> >> >> >> -- >> >> 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?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 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?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 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?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 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?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 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?hl=en-US. For more options, visit https://groups.google.com/groups/opt_out.
