I use numpy because the general multivector in an n-dimensional space
has 2**n
components and each component can be a scalar sympy expression. I use a
numpy array to store the coefficients for each grade of the multivector
since numpy
arrays can be stuffed with sympy expressions and component wise inherit
*, +, and -
from sympy so that is "A" and "B" are numpy arrays of the same shape
stuffed with sympy
expressions then A+B and A-B make sense.
Since you are interested in simulating dynamical systems I would suggest
looking at
"New Foundations for Classical Mechanics" by David Hestenes and some of
the chapters
in "Geometric Algebra for Physicist" by Doran and Lasenby. One
interesting exercise is to
see how the rotor formulation of the two body problem turns it into
solving an harmonic
oscillator. This is because if x(t) is the relative position vector of
the two bodies it can be
written as x(t) = R(t)*x(0)*reverse(R(t)) where R(t) is a time dependent
rotor (In three dimensions
a multivector with scalar and bivector components) that obeys the
harmonic oscillator equation.
On 05/10/2011 01:50 PM, Luke wrote:
Alan,
From what I can see in GA.py, you have one class MV, which doesn't
derive from anything, and then you use the setup method to somehow
inject MV objects into the global namespace. So, then, if x is a
sympy expression, and e is a MV object:
type(x*e) == type(e*x) ==<class 'sympy.galgebra.GA.MV'>
This is the sort of behavior I would like to have as far as scalar
multiplication of a UnitVector or Vector by a sympy expression goes.
It looks like you achieved this by defining the __mul__ and __rmul__
methods in the MV class, which then call your geometric_product
method. In geometric_product, if only one of the operands is a MV
object, you assume the other is a scalar and call the scalar_mul
method, which then does the distribution of the scalar across all the
elements in self.mv. A bit surpisingly, you seem to depend self.mv
being a numpy.ndarray for this to work properly, but I am sure you
have some reasons for this.
The question then seems to be what are the benefits or drawbacks of
subclassing from Expr? Perhaps if few or none of the methods in Expr
would make sense to call on UnitVector or Vector objects, they
shouldn't subclass from Expr and instead should just be standalone
classes that implement only the methods that make sense for them,
including the __mul__ and __rmul__ methods, as Alan did in his MV
class?
~Luke
On Tue, May 10, 2011 at 5:44 AM, Alan Bromborsky<[email protected]> wrote:
The assumption is that the expression multiplying the vector (multivector)
is a scalar and the
result is a vector. The geometric algebra is instantiated by defining a set
of abstract vectors
say e1, e2, e3, e4 and the dot product of all pairs of the vectors. These
dot products can be
symbols or numbers. The default option is that the dot product of ei and ej
is the symbol eidotej
and printed as ei.ej. The operator for the dot product is "|" so that
"print e1|e2" returns "(e1.e2)".
Thus if you define vectors - (a1,a2,b1,and b2 are sympy symbols)
a = a1*e1+a2*e2
b = b1*e1+b2*e2
Then there are three products
print a|b -> a1*b1*(e1sq)+a2*b2*(e2sq)+(a1*b2+a2*b1)*(e1.e2)
where in the dot product e1.e2 = e2.e1
print a*b -> a1*b1*(e1sq)+a2*b2*(e2sqr)+a1*b2*(e1e2)+a2*b1*(e2e1)
where in the geometric product e1*e1=e1sq and e2*e2=e2sq
print a^b -> (a1*b2-a2*b1)*(e1^e2)
where in the wedge product e1^e1=e2^e2=0 and e1^e2=-e2^e1
The geometric product of two vectors can be reduced via
a*b = a|b+a^b
using e1*e1 = e1sq, e2*e2 = e2sq, e1*e2 = (e1.e2)+e1^e2, and e2*e1 =
(e1.e2)+e2^e1 = (e1.e2)-e1^e2.
Also
a|b = (a*b+b*a)/2 and a^b = (a*b-b*a)/2
On 05/09/2011 08:51 PM, Luke wrote:
Can the vectors and multivectors in the GA module work with arbitrary
sympy expressions? i.e, if v is a GA vector, and s is a sympy
expression, does it make sense to do: s*v? Is the result of type Mul
or of something else?
~Luke
On Mon, May 9, 2011 at 5:42 PM, Alan Bromborsky<[email protected]>
wrote:
On 05/09/2011 08:30 PM, Luke wrote:
Here is a more explicit example of what Gilbert is talking about:
In [1]: from sympy import *
In [2]: from pydy import *
In [3]: x = symbols('x')
In [4]: N = ReferenceFrame('N')
In [5]: type(N[1])
Out[5]: pydy.pydy.UnitVector
In [9]: test = x*N[1] + x*x*N[2]
In [10]: type(test)
Out[10]: sympy.core.add.Add
In [11]: test2 = Vector(test)
In [12]: test2
Out[12]: x*n1> + x**2*n2>
In [13]: type(test2)
Out[13]: pydy.pydy.Vector
In [14]: test3 = x*test2
In [15]: test3
Out[15]: x*x*n1> + x**2*n2>
In [16]: type(test3)
Out[16]: sympy.core.mul.Mul
As you can see, in Out[15], the multiplication of x and test2 is being
printed in a way that doesn't make sense, and in Out[16] we can see
that this multiplication isn't resulting in another Vector object,
instead it is of type Mul.
Currently, to create a Vector object, you need to explicitly call
Vector on a sympy expression that is composed from terms that have
UnitVectors in them, or pass a dictionary with UnitVectors as the keys
and sympy expressions as the values.
Once you have that Vector object, you might want to multiply it by a
scalar (sympy expression) and have it return another Vector object.
This could be done using a somewhat user unfriendly approach:
In [22]: Vector(dict([(k, x*v) for k, v in test2.dict.items()]))
Out[22]: x**2*n1> + x**3*n2>
This gets the job done, but it isn't very convenient.
So basically, the question is whether
1) Is it easy enough in Sympy to make something like x*aVectorObject
evaluate to another Vector object? Where the x is a "scalar part"
(probably a sympy Expression) and aVectorObject is of type Vector
(which currently subclasses from Basic)?
2) Or is it ok to have to be more explicit about creating Vector
objects by using the notation Vector(x**2*N[1] + x**3*N[2]) or
Vector({N[1]: x**2, N[2]:x**3})?
Additionally, there are other types of products that make sense for
Vector and UnitVector objects, namely dot, cross, and outer products.
So the stuff above would only be for multiplying a Vector by a scalar.
I think all the other types of products have to make use of explicit
method calls since there would be no way to know which type of product
would be implied.
~Luke
On Mon, May 9, 2011 at 4:23 PM, Gilbert Gede<[email protected]>
wrote:
In PyDy (which we plan to merge into SymPy.physics.classical this
summer)
Vector is one of the classes already implemented (along with
UnitVector).
Vectors extend Basic, and UnitVector extend Expr.
The way it works now, you can't use Vector as part of a SymPy
expression:
In [57]: test
Out[57]: x*n1> + x*a1>
In [58]: x*test*x
Out[58]: x**2*x*n1> + x*a1>
Do people want to be able to use Vector (which comes with dot, cross,
outer
products, and derivative (between reference frames) functions
implemented)
in SymPy expressions? Or is it the type of thing no one really wants?
I'm looking forward to getting to work on PyDy& SymPy this summer.
-Gilbert
--
You received this message because you are subscribed to the Google
Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
GA module has vectors and multivectors. See documentation
http://docs.sympy.org/dev/modules/galgebra/GA/GAsympy.html
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
