On Wednesday, March 13, 2013 4:00:11 AM UTC+5:30, Gilbert Gede wrote:
>
> 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?
>
Yes. That sounds perfectly alright to me.
But, as Stefan pointed out, we need to be very clear in taking the correct
transformation of the basis vectors. In this example, the vector u defined
is ambiguous because we do not know the values of e_r, e_theta and e_phi
(more precisely, we also need another point in space* where *this vector is
defined).
Indeed, we can just take the default values of e_r, r_theta, e_phi to be at
origin of coordinates but I think that isn't very explicit (python zen).
Again, I'd like to reiterate my point about the CoordSystem class. This
class will contain all the information required for the transformations to
other coordinate systems. So, adding v and u, or taking dot product will
not be a problem.
>
> 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?
>
That can be one way, but, as was mentioned before, this way is too
mechanics oriented. What I'd like is a more direct interface to the
vectors. Also, attaching a basis will be taken care of by the attaching
another CoorSystem object which is basically a wrapper to all
functionalities for any coordinate system.
@Stefan: Okay then.
So, let us have a poll here. Would it be better to go for R3 or Rn?
Certainly, R3 would be easier for me. Also the concepts and applications
(use cases) will come more naturally in R3 . Also, there are several other
points that Stefan has mentioned before.
On the other hand, Rn would be the more general approach. I'll have some
problems with Rn though. First, I'll have to read some tensor analysis.
That won't take too long though. The other problem would finding use cases
(since I have to make the module so that the use cases will be covered in
the implementation) and making my implementation to *fit* the stuff already
made in mechanics.
That being said, I personally favour the R3 implementation.
So, please provide your views on this.
--
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.
