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. -- 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/0bc10fe4-d9f8-4a2e-b244-32cdc0ee9b70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
