Why should returning a Vector from a frame method be a problem? I prefer the second method, because it will be easier for the coordsys to operate on the vector its been provided (substituting base scalars, multiplying by dcm etc), than the method of vector making a copy of itself and operating on it. Conceptually and from the point of view of OO-design, it dosent make a difference. They mean the same.
Also, I will re-ask a doubt I had about Prasoon's code...Prasoon, why have you disallowed base scalars from appearing in velocity/accln vectors provided on initialization? On Sun, Jul 7, 2013 at 3:01 AM, Gilbert Gede <gilbertg...@gmail.com> wrote: > I think Sachin has some good suggestions. I would advocate something > similar (which is also similar to what mechanics currently has): why not > just create the base scalars and basis vectors upon initialization of a > coordinate system? There should only be one set of basis vectors and base > scalars for a coordinate system, so I think it makes the most sense to > create them upon initialization, then return them as needed. I think this > gets around the need to cache them, although you still can and I believe > should cache them (for example, all sympy symbols are cached). > > I also agree on sticking to the current mechanics style of not having the > user directly call the Vector() class, but then again, I am certainly > biased towards the mechanics approach... > This was certainly a decision based off my opinion, but it just seemed > more "correct" and natural to only create vectors from scalar/basis-vector > combinations and not by initializing them directly. > > Also, what are people's thoughts on the following: > Instead of > > some_vector.express_in(some_coord_sys) > some_vector.diff(x, frame=some_ref_frame) > > using > > some_coord_sys.express(some_vector) > some_ref_frame.diff(some_vector, x) > > The first option is similar to how mechanics is currently set up, and you > are returning a Vector from a method of Vector. > I feel like the second option is a little cleaner, but you are returning a > Vector from a CoordinateSystem/MovingRefFrame method. > > > > On Sat, Jul 6, 2013 at 4:52 AM, Sachin Joglekar > <srjoglekar...@gmail.com>wrote: > >> Two things- >> 1.) I think we should stick to the current mechanics framework's ideology >> of not letting the user initialize a base scalar/vector. As I have >> commented on your PR, we can define __getattr__ and __getitem__ methods for >> the CoordSys class, which would enable a user to use the 3rd (say) basis >> vector with R.3, and the 3rd base scalar with R[3] >> >> 2.) Now, coming to the creation of base vectors/scalars. I like your idea >> of caching them. The main reason I feel this should be done is, we don't >> really need two or more instances of a base vector/scalar in one run. So, >> we can define a helper method to initialise a base scalar- >> >> _generate_base_vector(coordsys, index) >> >> Hence, when the user says R[2], R's __getitem__ will call >> '_generate_base_vector(self, 2)'. Now we can use function memoization for >> this method. We can create a custom cache which stores a tuple of the >> coordinate system and the index as the key. So the next time the same >> method is called for R[2], the pre-generated instance will be returned. >> >> Same can be done for basis vectors. I had written a blog post about >> function memoization, and I guess it will work here with some modification. >> >> 1) and 2) will eliminate any ambiguity regarding base vectors/scalars and >> also provide a cleaner interface for the whole operation. >> >> >> On Sat, Jul 6, 2013 at 4:19 PM, Prasoon Shukla >> <prasoon92.i...@gmail.com>wrote: >> >>> @Gilbert, @Sachin, @Stefan : I am facing a bit of a problem that I have >>> written about in this week's blog >>> here<http://musingsofafriend.wordpress.com/2013/07/06/gsoc-week-3-sympy-development-finishing-the-basic-structure/>. >>> Please see the second part of the blog where I mention about a cache to >>> hold relationships between coordinate system and base scalars and base >>> vectors. Please comment your views here. >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "sympy" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/sympy/t-Je0beTIIU/unsubscribe. >>> To unsubscribe from this group and all its topics, 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 a topic in the > Google Groups "sympy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sympy/t-Je0beTIIU/unsubscribe. > To unsubscribe from this group and all its topics, 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.
