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