Lie Group Class?

[Joy merwin monteiro]

Hello,

I have been looking at the sympy code for a bit, especially the diffgeom module.
It seems quite comprehensive, and was wondering if there has been thinking
along the lines of creating a Lie Group class which subclasses from Manifold and Group (? can't
find an abstract class of this type). One could then create various instances of it, add
a coordinate system and a Lie Algebra to it for computations (analogous to what is done in diffgeom.rn).

My motivation for asking this is that Lie group based algorithms are present in the ode module
 and some code is also present in the liealgebra module (though it does not seem to have an
algorithmic focus), and I felt it would tie things up nicely in terms
of structure. Symmetry methods for differential equations also conceptualise the DE as a manifold itself, unless I'm mistaken.
In the (distant!) future I would like to contribute some algorithms for symmetry methods in PDEs,
(which is why I looked at Sympy in the first place), but thought this would be something more feasible and
will also allow me to familiarise myself with the sympy codebase.

Look forward to any opinions/suggestions with regards to the feasibility of something like this. Belated
Xmas wishes to all!

TIA,
Joy

[Francesco Bonazzi]

sympy.diffgeom has been inspired by this source:

http://groups.csail.mit.edu/mac/users/gjs/6946/calculus-indexed.pdf

The code in that PDF is written in Scheme (a Lisp dialect). I don't know whether you have experience with that programming language, but it's quite hard to read. The module sympy.diffgeom can be thought of a kind of translation of the Scheme code into object-oriented Python code.

Apparently someone already thought of extending the Scheme code to deal with Lie groups, and did it:
http://wmfarr.blogspot.it/2006/06/functional-differential-geometry-in.html

I have no idea about this work, anyways. The link to that blogger's code extension looks to be broken.

[Joy merwin monteiro]

Thanks, Francesco. I have a little familiarity with Scheme, mainly due to my
many attempts to read SICM. Thanks for that link, have mailed the author of that
blog.

You might have also come across https://github.com/davidsd/lie

Having a look at this as well, hopefully something will click!

Thanks,

Joy

--
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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/bb8833fa-0877-433a-ab7f-e935f0e5fdaf%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

The best ruler, when he finishes his
tasks and completes his affairs,
the people say
“It all happened naturally”
                                      
                                         - Te Tao Ch'ing

[Joy merwin monteiro]

Hello,

a couple of things struck me when I was looking at the mail regarding a proposed

group theory project by Vamsi.

a) The manifolds in rn.py just need to setup a coordinate system, since the parameterisation
is the identity map. How would one describe, say, Sn? Wouldn't Patch require an additional

attribute which maps the coordinate system to the actual surface? In the same vein, if one
defines patches, should there not be a way to check that the resulting patchwork is indeed
a manifold, i.e, that continuity is satisfied?

b) can we simply do plot(manifold) to visualise it?

Since this seems to be of a more elementary nature as compared to the LieGroup thing,

I think it will be a good exercise to write sn.py in the nature of rn.py which implements

 S1 and S2. It should also help me get a better hang of the code. I would also not mind

doing the plot(manifold) functionality if it does not exist.

Look forward to any pointers!

Joy

[Francesco Bonazzi]

On Sunday, December 28, 2014 5:26:40 AM UTC+1, Joy merwin monteiro wrote:

Hello,

a couple of things struck me when I was looking at the mail regarding a proposed

group theory project by Vamsi.

a) The manifolds in rn.py just need to setup a coordinate system, since the parameterisation
is the identity map. How would one describe, say, Sn?

Supposing you mean the N-sphere by Sn, a sphere cannot be mapped by one single patch. You need at least two. Patches are currently just containers, there is no way as of now to define coordinate transition functions between overlapping patches.

Anyways, I don't think that a manifold should be represented by its embedding into the Euclidean space (in the case of Sn, a map from one vector of Sn to a vector in R_(n+1) ). Once you have a coordinate system on a patch, you can define your own function mapping its coordinates to the Euclidean space.
 

 

b) can we simply do plot(manifold) to visualise it?

Visualizing a manifold depends on the embedding you choose. A plot is basically a projection from the manifold to 2D or 3D Euclidean space, so as soon as you have a map to do that, you can plot the manifold.
 

Since this seems to be of a more elementary nature as compared to the LieGroup thing,

I think it will be a good exercise to write sn.py in the nature of rn.py which implements

 S1 and S2. It should also help me get a better hang of the code.

As there are currently no ways to define transition functions among patches, defining S1 and S2 is identicaly to define R1 and R2.

[Joy merwin monteiro]

Thanks, Francesco.

Supposing you mean the N-sphere by Sn, a sphere cannot be mapped by one single patch. You need at least two. Patches are currently just containers, there is no way as of now to define coordinate transition functions between overlapping patches.

Yes, I noticed that the Patch class would not be able to do this. Hence, I was thinking being able to represent

Sn consistently would be a useful use-case to add the required machinery, if you think something like this makes
sense.

 

Anyways, I don't think that a manifold should be represented by its embedding into the Euclidean space (in the case of Sn, a map from one vector of Sn to a vector in R_(n+1) ). Once you have a coordinate system on a patch, you can define your own function mapping its coordinates to the Euclidean space.

I agree with you, this is probably the correct approach. Then the question is, where would this function exist

within Sympy? Should a Manifold class, which would contain the patches, contain an optional Embedding class/attribute

corresponding to each Patch?

 

Visualizing a manifold depends on the embedding you choose. A plot is basically a projection from the manifold to 2D or 3D Euclidean space, so as soon as you have a map to do that, you can plot the manifold.

Agreed. Going back to my previous paragraph, what do you think is the best way to handle such a map (and hence the
plotting capability)?

 

As there are currently no ways to define transition functions among patches, defining S1 and S2 is identicaly to define R1 and R2.

Then, the only way to tell S1 and R1 apart would be to associate them with a metric? Then again, where should this

metric be stored?

Thanks,

Joy

[Francesco Bonazzi]

On Sunday, December 28, 2014 10:50:08 AM UTC+1, Joy merwin monteiro wrote:

Thanks, Francesco.

Supposing you mean the N-sphere by Sn, a sphere cannot be mapped by one single patch. You need at least two. Patches are currently just containers, there is no way as of now to define coordinate transition functions between overlapping patches.

Yes, I noticed that the Patch class would not be able to do this. Hence, I was thinking being able to represent

Sn consistently would be a useful use-case to add the required machinery, if you think something like this makes
sense.

There is already a machinery to connect two CoordSystem objects defined on the same Patch. Maybe that could be extended to connect two CoordSystem objects defined on two different patches of the same manifold. Obviously, there should also be a connection between two patches, maybe by just defining a function that returns a boolean indicating whether a Point is on the patches overlap or whether it is not.

The question is, how much do we really need this part? Many users would like to use sympy.diffgeom to handle long calculations easily, by using a Computer Algebra System. One would just want to set up a coordinate system and stay on that coordinate system to do extensive calculations on that coordinate system, like the calculation of the Riemann tensor and so on. Otherwise, writing tools to convert from one coordinate system to another on the same patch are also useful, because that generally save a lot of hand calculations. But would there be many users interested in representing the topological structure of a manifold by inequalities and equations among coordinate systems? I don't think so.

Anyways, I don't think that a manifold should be represented by its embedding into the Euclidean space (in the case of Sn, a map from one vector of Sn to a vector in R_(n+1) ). Once you have a coordinate system on a patch, you can define your own function mapping its coordinates to the Euclidean space.

I agree with you, this is probably the correct approach. Then the question is, where would this function exist

within Sympy? Should a Manifold class, which would contain the patches, contain an optional Embedding class/attribute

corresponding to each Patch?

SymPy classes should contain just the essential to identify the object uniquely. If you want to define an embedding, just define a function in the namespace you're working, not inside the Manifold/Patch classes.

 

Visualizing a manifold depends on the embedding you choose. A plot is basically a projection from the manifold to 2D or 3D Euclidean space, so as soon as you have a map to do that, you can plot the manifold.

Agreed. Going back to my previous paragraph, what do you think is the best way to handle such a map (and hence the
plotting capability)?

Define a function in your namespace. I would not modify existing diffgeom classes.
 

As there are currently no ways to define transition functions among patches, defining S1 and S2 is identicaly to define R1 and R2.

Then, the only way to tell S1 and R1 apart would be to associate them with a metric? Then again, where should this

metric be stored?

I don't think it has to do with the metric, S1 and R1 are still different manifolds even if you don't define a metric. The distinction is determined by their topology.

But now we are departing from the topic, which was about Lie groups. I think the best way to act on sympy.diffgeom in this regard is by getting the Scheme code by Will Farr and translate that into SymPy code.

[Joy merwin monteiro]

Thanks. I agree with your views regarding the mapping business. I guess it is best
to keep them specific to an application.

I realise that S1 and R1 have different topologies. The reason I asked about the metric was in the

context of the information stored within Manifold/Patch (which contains nothing about the topology,

which is fine), there is no way to distinguish the two, like you mentioned previously. But yes, this
is off-topic and not for this thread.

Hope Will Farr gets back at least with a design outline, if he has lost the code. The LiE package

that I was looking at represents Lie Groups in terms of their Lie Algebras, which is useful for
computation, but is not directly in-line with the spirit of scipy.diffgeom as it exists. A LieGroup

will definitely provide a bridge for more extensive work. Let's see!

Joy

[Alan Bromborsky]

Because of you interest in Lie groups you might find the attached paper of interest -

--
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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CA%2BphhE%3D9n8yVPoBid%2BCZ%3DOqa7vc39XyPop3EzEuEfXEQgfhvEg%40mail.gmail.com.

[Joy merwin monteiro]

Thanks, Alan. Looks interesting!

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/54A00C67.6080202%40verizon.net.

For more options, visit https://groups.google.com/d/optout.