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 On Sun, Dec 28, 2014 at 3:50 PM, Francesco Bonazzi <[email protected]> wrote: > > > 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. > -- The best ruler, when he finishes his tasks and completes his affairs, the people say “It all happened naturally” - Te Tao Ch'ing -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CA%2BphhE%3D9n8yVPoBid%2BCZ%3DOqa7vc39XyPop3EzEuEfXEQgfhvEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
