Add Spheres smoothly embedded in Euclidean Space to Manifold Catalog

[mjungmath]

See #30189.

The current catalog only provides spheres of dimension two. A comprehensive and faster version will be added here.

Features:

• spherical and stereographic coordinates
• orientation
• radius and barycenter can be stated
• link to minimal triangulation in homology module
• initialized embedding such that extrinsic quantities can be derived

Follow-Ups:

• make S^1, S^3 and S^7 parallelizable
• Hopf coordinates on S^3
• link to Lie group structure on S^1 and S^3

CC: @egourgoulhon @tscrim @tobiasdiez

Component: manifolds

Author: Michael Jung

Branch: caa9d5f

Reviewer: Eric Gourgoulhon, Travis Scrimshaw

Issue created by migration from https://trac.sagemath.org/ticket/30804

[mjungmath]

comment:2

Establishing the stereographic projection in more than 3 dimensions is very demanding, even if you know the inverse. I know that you can speed these things up a little by turning off checking and choosing a suitable simplification. But do you know more workarounds?

I also suspect that the Jacobian takes a long time.

[tscrim]

comment:3

Even if it takes a long time, IMO it still is good to have a general version (with a warning to the user about the time).

[mjungmath]

comment:4

I agree. It is good to have these examples.

I thought about computing the desired quantities only on demand. Unfortunately it turned out difficult since most quantities are integral components and invoked by attributes not by methods. That's why I usually prefer methods rather than attributes.

[mjungmath]

Branch: u/gh-mjungmath/add_standard_sphere_to_manifold_catalog

[mjungmath]

comment:6

Please take a peek at this first approach. I'd appreciate if someone can take a closer look at the details, i.e. transition maps, choice of subsets etc.

I tried to cover spherical coordinates in arbitrary dimensions as well. But it turned out that the transition map to the stereographic coordinates is a bit complicated in the general setup. I welcome any kind of reference that might help. Furthermore, I wanted to ensure that the spherical coordinates have the correct orientation right from the start. That explains the reordering of coordinates compared to Wikipedia, and it makes the transition map to figure out even more tricky.

---

New commits:

bf4440a

Trac #30804: first n-sphere approach

[mjungmath]

Commit: bf4440a

[sagetrac-git]

Changed commit from bf4440a to 3ea0f27

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

3ea0f27

Trac #30804: transition spher <-> stereo added

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

245d563

Trac #30804: transition maps corrected

[sagetrac-git]

Changed commit from 3ea0f27 to 245d563

[mjungmath]

comment:10

This should be the correct transition map, now. Checks all pass, too. I hope I didn't mess up the domains. Please check. Examples follow.

[sagetrac-git]

Changed commit from 245d563 to 6215d79

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

6215d79

Trac #30804: transition spher <-> stereo added

[egourgoulhon]

comment:12

Replying to @mjungmath:

I tried to cover spherical coordinates in arbitrary dimensions as well. But it turned out that the transition map to the stereographic coordinates is a bit complicated in the general setup. I welcome any kind of reference that might help.

A very good reference for the sphere in any dimension is Chapter 18 The sphere for its own sake in Marcel Berger: Geometry, vol. II, Universitext. Springer-Verlag, Berlin, 1987.

Furthermore, I wanted to ensure that the spherical coordinates have the correct orientation right from the start. That explains the reordering of coordinates compared to Wikipedia, and it makes the transition map to figure out even more tricky.

On general grounds, I don't think we should depart from Wikipedia conventions without a good reason. Moreover, I think it is standard convention to have the periodic coordinate on Sⁿ to be the last one (as in (theta, phi) for S²), not the first one.

[mjungmath]

comment:13

Replying to @egourgoulhon:

Replying to @mjungmath:

I tried to cover spherical coordinates in arbitrary dimensions as well. But it turned out that the transition map to the stereographic coordinates is a bit complicated in the general setup. I welcome any kind of reference that might help.

A very good reference for the sphere in any dimension is Chapter 18 The sphere for its own sake in Marcel Berger: Geometry, vol. II, Universitext. Springer-Verlag, Berlin, 1987.

Thanks. I'll take a look.

Furthermore, I wanted to ensure that the spherical coordinates have the correct orientation right from the start. That explains the reordering of coordinates compared to Wikipedia, and it makes the transition map to figure out even more tricky.

On general grounds, I don't think we should depart from Wikipedia conventions without a good reason. Moreover, I think it is standard convention to have the periodic coordinate on Sⁿ to be the last one (as in (theta, phi) for S²), not the first one.

We have to deviate from the Wikipedia convention anyway.

This is simply because the slit we take out for spherical coordinates should meet the poles. Currently, the north/south pole is encoded in the last coordinate. We can shift it to the first, and then we can recover the conventions in Wikipedia for spherical coordinates. But that would be another convention we break, namely for the stereographic projection.

[egourgoulhon]

comment:14

Replying to @mjungmath:

We have to deviate from the Wikipedia convention anyway.

This is simply because the slit we take out for spherical coordinates should meet the poles. Currently, the north/south pole is encoded in the last coordinate. We can shift it to the first, and then we can recover the conventions in Wikipedia for spherical coordinates. But that would be another convention we break, namely for the stereographic projection.

Sorry I don't understand what you mean. It seems to me that we can keep Wikipedia conventions, both for spherical coordinates and stereographic ones, as we do already for S² in this example. Then the spherical frame and the stereographic frame from the South pole are right-handed and the stereographic frame from the North pole is left-handed.

[mjungmath]

comment:15

Replying to @egourgoulhon:

Replying to @mjungmath:

We have to deviate from the Wikipedia convention anyway.

This is simply because the slit we take out for spherical coordinates should meet the poles. Currently, the north/south pole is encoded in the last coordinate. We can shift it to the first, and then we can recover the conventions in Wikipedia for spherical coordinates. But that would be another convention we break, namely for the stereographic projection.

Sorry I don't understand what you mean. It seems to me that we can keep Wikipedia conventions, both for spherical coordinates and stereographic ones, as we do already for S² in this example. Then the spherical frame and the stereographic frame from the South pole are right-handed and the stereographic frame from the North pole is left-handed.

That's right. But notice that the convention in the general case is slightly different than in the 2-sphere case, compare [https://en.wikipedia.org/wiki/N-sphere#Spherical_coordinates [1]] with [https://en.wikipedia.org/wiki/Spherical_coordinate_system#Cartesian_coordinates [2]]. If you consider the embedding in spherical coordinates in the general case, and follow the convention [1], it appears to happen that the poles do not belong to the removed meridian.

So what I did was reversing the order of the x_i and phi_i simultanously (compare [1]) in hope to find a consistent formula. Turns out that everything behaves nicely in this setup: the implementation is easy and the inverse looks comparably nice. One even gets an oriented coordinate frame on top.

Whatever convention we choose, I will provide a thorough documentation of the conventions used in the implementation anyway.

[mjungmath]

comment:16

Attachment: spherical.png

I have added the choice of coordinates and their inverse in an attachment. I think the formulas look very nice this way (provided I haven't miscalculated).

[mjungmath]

comment:19

I see these options:

1. Keep it the way I suggested.
2. Break the convention for the stereographic projection, and put the poles to the first coordinate, then use the convention [https://en.wikipedia.org/wiki/N-sphere#Spherical_coordinates [1]].
3. Use suggestion 1 or 2 and separate the 2-sphere to obtain convention [https://en.wikipedia.org/wiki/Spherical_coordinate_system#Cartesian_coordinates [2]].
4. Keep the stereographic convention, alter the convention [https://en.wikipedia.org/wiki/N-sphere#Spherical_coordinates [1]] in such a way that we obtain convention [https://en.wikipedia.org/wiki/Spherical_coordinate_system#Cartesian_coordinates [2]] for the 2-sphere case.

I personally vote for 1 as long as the documentation is thorough enough.

[mjungmath]

comment:21

I gave it a little thought. I think option 4 is best. Option 4 is in a way canonical: we obtain the convention for S^1 and for S^2. It is only plausible then that the convention should be kept for higher dimensions as well (I don't know why it isn't so).

In addition, we don't need an extra class with facade pattern for 1D and 2D.

Agreed?

[tobiasdiez]

comment:22

This sounds like a good plan.

I'm not sure if that works, but is it possible to add all these different conventions as additional charts? Then the user can decide which convention he wants to follow. This would also be the most flexible approach (e.g. to verify formulas in different conventions etc).

[mjungmath]

comment:23

Replying to @tobiasdiez:

I'm not sure if that works, but is it possible to add all these different conventions as additional charts? Then the user can decide which convention he wants to follow. This would also be the most flexible approach (e.g. to verify formulas in different conventions etc).

I agree that this would be the best option. But I suspect that it is not worth the effort. Furthermore, these details can be added by time. I think, a non-primitive working sphere example in any dimension is enough for now.

[mjungmath]

comment:39

By the way, I noticed that there is no section in the documentation dedicated to general examples (except for EuclideanSpace). This should be expanded when more examples of this kind are added.

[tscrim]

comment:40

You can just set it to needs review now; if there are more comments then people can provide it then.

[sagetrac-git]

Changed commit from f3b4d86 to 95982e8

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

1152908	Trac #30804: first n-sphere approach
6edafec	Trac #30799: collect manifolds examples in 'examples' + lazy_import for catalog
95982e8	Trac #30804: code and docstring finished

[mjungmath]

comment:42

Squashed commits. Ready for review.

[mjungmath]

Author: Michael Jung

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

dfb6045

Trac #30804: Merge branch 'develop' into t/30804/add_standard_sphere_to_manifold_catalog

[sagetrac-git]

Changed commit from 95982e8 to dfb6045

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

caa9d5f

Trac #30804: improved orientation example

[sagetrac-git]

Changed commit from dfb6045 to caa9d5f

[mjungmath]

comment:47

Patchbot full green.

[egourgoulhon]

Reviewer: Eric Gourgoulhon, Travis Scrimshaw

[egourgoulhon]

comment:48

Good for me. Travis, do you agree?

[tscrim]

comment:49

Yep, I agree.

[mjungmath]

comment:50

Thank you! :)

Eric, would you mind going for the Hopf coordinates?

[egourgoulhon]

comment:51

Replying to @mjungmath:

Thank you! :)

Thank you for this work.

Eric, would you mind going for the Hopf coordinates?

I'll be happy to make a ticket for S³ as a subclass of Sphere, but at the moment I am busy by other things, as you may have guessed from my slowness in reacting to Sage tickets.

[vbraun]

Changed branch from u/gh-mjungmath/add_standard_sphere_to_manifold_catalog to caa9d5f

[egourgoulhon]

Changed commit from caa9d5f to none

[egourgoulhon]

comment:53

See #31781 for a follow-up.