I think Stefan probably did a better job with the terminology than I could
do, and covered a lot of points. Unfortunately, as a mechanical engineer,
my terminology is a bit sloppy on these topics.
What ReferenceFrame really does, is provide a set of orthonormal basis
vectors to define other vectors with; ReferenceFrame also provides
functionality for keeping track of rotations between these orthonormal
bases. The concept of an inertial frame is specified later, when equations
of motion are constructed and it matters (I'm not sure if that is true for
EM fields?). We didn't really allow for translation of ReferenceFrame's,
but instead wrote it as if there was no knowledge of translation
position/velocity/acceleration of one ReferenceFrame w.r.t. another. This
places the burden on the end user to correctly define velocities of points
in multiple frames.
In mechanics, we treated all vectors as vector functions. We didn't really
make a distinction between bound and free vectors - there didn't seem to be
a "clean" way to do it.
Perhaps you could change the ReferenceFrame of mechanics into something
such as OrthonormalBasis? Other basis types could then be created. A
ReferenceFrame would then need to be instantiated with a basis type. This
could allow multiple bases to be embedded within one ReferenceFrame (all
fixed relative to each other). While I've never attempted (nor needed to
nor previously thought about) this, I would imagine that you could extend
this to include other types of bases (e.g. spherical) and still allow for
algebraic operations between vectors defined in this way.
Example:
If we had a vector written with an orthonormal basis: v = 1 * e_x + 2 * e_y
+ 3 * e_z
and another written with a spherical basis: u = 4 * e_r + 5 * e_theta + 6 *
e_phi
that they could be added/subtracted/dotted, e.g. u + v = 1 * e_x + 2 * e_y
+ 3 * e_z + 4 * e_r + 5 * e_theta + 6 * e_phi
Does that sound right?
Maybe the code could look something like this:
A = ReferenceFrame('A', 'orthonormal')
A.attach_basis('spherical', _some_initial_orientation_info_)
v = A.x + A.y
u = A.r + A.theta
Maybe it's possible to extend this to include translational information
also?
On Tuesday, 12 March 2013 09:27:18 UTC-7, Prasoon Shukla wrote:
>
> First, sorry for replying so late. Had some assignments to complete (still
> do :P )
> Second, thanks a lot for elucidating everything in such detail. I am
> constantly amazed by the wonderful community response here. Thank you all
> for that.
>
> Now, getting back to the topic of discussion,
> On Tuesday, March 12, 2013 12:43:28 AM UTC+5:30, Stefan Krastanov wrote:
>>
>> First of all, I think it would be nice to start writing a wiki page
>> with the proposal as the general idea seems clear enough.
>>
>
> Yes. I'll start with the proposal shortly; I still need to coordinate
> with Sachin for his proposed electrodynamics module.
>
> Second (and most important in this message), I would vote for
>> completely forgetting about anything outside 3D. Implementations of
>> vector calculus in Rn should be done (and are done to some extend) in
>> the geometrical algebra and differential geometry modules (and the
>> tensor canonicalization pull request by Pernici). The whole idea of a
>> vector calculus module, in my opinion, is that when working in R3 you
>> do not need all these generalized notions of, e.g, curl or vector
>> product in terms of completely antisymmetric tensors.
>>
>> Obviously, we would love to have `rewrite_as` methods to couple it to
>> the diffgeom/ga/tensor modules but that does not mean it is a good
>> idea to use, for instance, the diffgeom module as a basis for your
>> project. It can be done and for puritans it will indeed be a deep
>> example of code deduplication/reuse and object oriented blah blah.
>> However, the code will be harder to understand and the obvious notions
>> of R3 calculus will be hidden behind their generalizations.
>>
>
> Implementing in R3 reduces quite a bit of my work - Now I don't have to
> read Tensor Analysis. And yes, keeping in line with my objectives,
> implementing in R3 will definitely be more accessible to the typical user.
> The rewrite_as method, as you mentioned, sounds really good to me for
> module interoperability.
>
>
>> And simply from a practical standpoint, the mechanics module is
>> already based around R2/R3. It is more important to abstract that away
>> than to generalize it to cases that will not be used.
>>
>> The rest of my comments are below, annotating your message.
>>
>> > @Gilbert: I have been thinking along the lines of the mechanics module
>> and
>> > as Stefan mentioned, I plan (at least right now) to take this idea
>> forward
>> > with component wise operations on vectors. For component independent
>> vector
>> > algebra, any numerical operation on any vector will inevitably get
>> reduced
>> > to operations on scalars (individual components). Therefore, I believe,
>> that
>> > a large part of component dependent vector operations will form a
>> subset to
>> > a more complete component independent vector algebra. So definitely, in
>> the
>> > long term, we will be able to extend this vector module to play nice
>> with
>> > component free vector algebra, just as Raoul mentioned.
>>
>> It is a bit unclear what you mean by "component dependent". Here are
>> the two ways this can be understood:
>>
>> 1. Simply using matrices without "metadata". I consider this a very
>> bad idea as a matrix is just a representation of the geometrical
>> entity vector and all that can be done this way is already in the
>> matrix module.
>> 2. Using some symbolic object containing
>> - reference to the "world" in which we work
>> - reference to the reference/basis in which we represent the vector
>> - the coordinates in this basis, which is a matrix
>>
>> EDIT: I see that you actually use the second approach. Great!
>>
>
> As you said, I am using approach number 2.
>
> > Also, and just as you mentioned, Vector in mechanics can be extended
>> because
>> > the user does not directly interact with vector objects. This means
>> that, at
>> > least for mechanics, we won't have too many problems as far as
>> integration
>> > with the new module is concerned. Of course, this problem remains for
>> other
>> > modules (quantum, electricity-magnetism modules proposed by Sachin).
>> For
>> > those, I will interact with people in the community for their
>> requirements
>> > and hopefully, decide on an idea that keeps everyone happy, or at
>> least,
>> > which keeps most of the people happy.
>>
>> I would say, leave quantum away. Hilbert spaces in quantum mechanics
>> are sufficiently different from R3 to necessitate their own
>> implementation. On the other hand, I strongly suggest that this
>> project you are preparing be the basis for the electrodynamics project
>> by Sachin. You should definitely work together on this.
>>
>> Alright then. In any case, I seem to be lacking the appropriate maths
> required for full-fledged treatment of quantum physics anyway.
>
>
>> > Now, let us talk a bit about the requirement of reference frames. The
>> > reference frames will, I think, be required only for R3 (as in case of
>> > mechanics). I wish to abstract the idea of a reference frame as
>> implemented
>> > in mechanics, albeit in a bit different way. The discussion on world
>> based
>> > coordinate system is what I wish to point out here in this respect.
>> > Currently, we need to have a RefrenceFrame for any vector. World
>> coordinates
>> > will allow vectors that just work and I think that it is a very
>> important
>> > feature to have from a user's point of view.
>>
>> Reference Frame makes sense outside mechanics (and for any dimension,
>> but as I said, I would like to see this project restricted to 3D done
>> right).
>>
>> You might be confusing the following notions (or maybe you do not, but
>> in any case let's just spell them out):
>>
>> - vector space vs affine space (or flat manifold): Physics and vector
>> analysis is __not__ done on vector spaces. Just look at your example
>> below: you have components of the vector (the vector space part) and
>> the coordinates of the point where this vector is (the manifold part).
>> - the basis is what you use to express the components of the vector
>> (the vector space part).
>> - the coordinate system is what you use to express the point in space
>> you are using.
>> - you can very well have two different cartesian coordinate systems
>> (centered at the same point but rotated wrt to each other or instead
>> parallel but with different origins). In the same way you can have two
>> different spherical coordinate systems.
>> - you may have noticed that the basis you use for the vectors can
>> change from point to point. For instance, the usual basis you use when
>> dealing with spherical coordinates is radial/longitudinal/latitudinal
>> vectors. However they change from point to point. This defines a
>> _frame_: having a frame is having a basis at each point of your space.
>>
>
> Yes of course. As a matter of fact, I had, at one point, considered the
> idea of implementing a RefranceFrame by using an origin of coordinates
> w.r.t. to world coordinates and using a basis defined at that origin (my
> point might not have come across very clearly here, I admit).
> Also, the fact that basis changes from point to point is taken care of by
> CoordSystem object passed to Vector (the way I see it as of yet). The
> operations (grad, curl, div etc) on a Vector will again be defined based on
> the CoordSystem object.
>
> - importantly, there is a canonical frame for each coordinate system
>> (the one you obtain by having unit vectors in the directions in which
>> coordinates change).
>> - A reference frame can be (depending on textbook): the coordinate
>> system, the frame, or both taken together. I do not know which is in
>> the mechanics module. Just stick to it, and refactor it out into your
>> own module.
>
> I think it would be good to refactor the above list, fix the
>> terminology you will be using and add it in your wiki page
>> application.
>>
>> > The current implementation that I have in mind will allow the user to
>> > directly instantiate a Vector. As an example, say I want to just
>> initialize
>> > a vector and find out its curl. So, the user should be able do
>> something
>> > like (just an example of how things could function):
>> >
>> >>>> from vector import *
>> >>>> from sympy.abc import x, y, z
>> >>>> coord = CoordSystem('rect')
>> >>>> v = Vector((-y, x, 0), (x, y, z), coord=coord)
>> >>>> div(v)
>> > 0
>> >>>> curl(v)
>> > 2*ez
>>
>> This seems sensible. You may want to abstract (x, y, z) out into a
>> Point class, as in diffgeom, however this might be excessive,
>> especially given that we do not mix coordinate systems with frames of
>> other coordinate systems
>>
>
> A Point class sound like a good idea to me. This way, we can define
> methods on the class which would help out a lot. As an example, we can have
> a method to rewrite the point coordinates for a different reference frame.
>
>
>> > Taking a clue from diffgeom, we are defining a coordinate system first
>> (with
>> > 'rect' providing the basic cartesian coordinates, the definitions of
>> which
>> > are inbuilt. We can have similar functionality for other commonly used
>> > coordinate systems). Then, we instantiate a vector and give it symbols
>> to
>> > use for coordinates. The dimension of the vector can be calculated
>> > internally using the second n-tuple. The basis for any Rn space will be
>> just
>> > the standard basis. Then, we can have component-wise operations that
>> produce
>> > the result; in this case divergence and curl of the given vector field.
>> > Also, for the n-dimension case, we can have something like:
>> >>>> v = Vector(dim=7, symbol=y, coord=coord)
>>
>> Mostly agree, but drop dim!=3. And I have a lot of technical comments
>> concerning the the `symbol` argument, but they can wait for later.
>
>
> Okay. Since we are going ahead with R3, so, dim will be 3 by default.
>
> >
>> > Here, the coord object will carry the relations with one of the
>> standard
>> > coordinate systems and that will be used to define all the operations
>> of
>> > vector calculus.( The coord object can be generated by performing
>> operations
>> > on CoordSystem object of some standard coordinate system perhaps?)
>> >
>> > This will generate a vector (unbound?) where the coordinates wrt to the
>> > standard basis (e1, ... , e7) are just (y1, y2, y3 ... y7).
>>
>> Concerning the very important "unbound?" question. In your first
>> example `Vector` is actually a vector field, i.e. bound vector for
>> physicists (there is a difference between vector field and a bound
>> vector but drop it for the moment). In your second example `Vector` is
>> actually a vector, not a vector field. Vector analysis cares about
>> vector fields, so just completely drop the unbounded vectors from your
>> proposal. They have place in linear algebra module, in matrix
>> expressions module and in hilbert spaces module (the quantum module),
>> not here.
>>
>
> Okay. I was just experimenting a bit so, yeah, will drop the idea of
> unbound vectors.
>
>>
>>
>
>> PS
>>
>> By the way, this question show an issue that must be discussed a lot
>> before we are clear about how to proceed. The mechanics module deals
>> with bounded vectors, not vector fields. The electrodynamics module
>> and your vector analysis module would deal with vector fields. How can
>> these two notions can be combined (is it possible/practical)? I would
>> like to see this discussed in your proposal.
>>
>> Here is an example of the issue:
>>
>> 1. a field
>> some_vortex_field = Vector((-y, x, 0), (x, y, z))
>>
>> 2. a bounded vector
>> some_force_on_some_point = Vector((1,2,0), (p_x, p_y, p_z))
>>
>> The first example is what one will do in electrodynamics do define
>> some field. You can calculate its curl for instance.
>>
>> The second example is something from the mechanics module. The point
>> is for instance some joint that we are studying and the vector is the
>> force at that point.
>>
>> Does it make sense to represent both these objects with the same class?
>
>
> I haven't thought of this in detail yet. But, at a first glance, my answer
> is yes. We can just have a property Vector.is_field that can be used to
> differentiate between the two different types. Also, if it's just a
> constant vector, then curl, div are both zero.
> Another way to go about this is inherent in the initialization of the
> vector. The second 3-tuple is actually used for getting the 'variables'
> that must be used in taking, say, the curl of the vector field. If we don't
> give out these variables explicitly, then the data members of Vector object
> that holds that 3-tuple is just going to be None. That way too, we can
> distinguish between vector fields and constant vectors.
>
> Anyway, as I mentioned before, things are very sketchy right now. Let me
> first talk with Sachin and try out mechanics a bit as well. I plan to make
> refinements in layers, fine tuning things till they are right. So, I'll
> begin writing a proposal soon, but I won't necessarily put it on the wiki
> just yet. Once I have something concrete, *then* I'd post it on the wiki.
> In the meanwhile, let's keep this thread for all discussions concerning the
> vector module.
>
> Again, thanks a ton for all the help.
>
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
