> 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.
The way I understand this is that, because `mechanics` works only with
cartesian coordinate systems for now, it does not need to distinguish
between coordinate system / basis / frame, because the coordinates are
not curved and all this notions turn out to be the same.
> 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?
I like the general idea.
> 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?
Actually this is not too different from what was done for the diffgeom
module (and the Scheme codebase that inspired it).
By the way, here with the spherical example one can see a difference
between the basis/frame and the coordinate system
- the coordinate system is not of straight lines that can be
identified with scalar*unit_vector
- the basis is of unit vectors (however these vectors change
direction from point to point)
> 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.
The fact that it works quite well for now makes me hopeful that it
will not be necessary to distinguish them (unbounded/bounded/field)
even in the proposed new module.
--
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.
