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 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.
