#30804 closed enhancement (fixed)
Add Spheres smoothly embedded in Euclidean Space to Manifold Catalog
Reported by:  ghmjungmath  Owned by:  

Priority:  major  Milestone:  sage9.3 
Component:  manifolds  Keywords:  
Cc:  egourgoulhon, tscrim, ghtobiasdiez  Merged in:  
Authors:  Michael Jung  Reviewers:  Eric Gourgoulhon, Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  caa9d5f (Commits, GitHub, GitLab)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
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
FollowUps:
 make
S^1
,S^3
andS^7
parallelizable  Hopf coordinates on
S^3
 link to Lie group structure on
S^1
andS^3
Attachments (1)
Change History (54)
comment:1 Changed 12 months ago by
 Cc egourgoulhon tscrim added
 Component changed from PLEASE CHANGE to manifolds
 Description modified (diff)
 Type changed from PLEASE CHANGE to enhancement
comment:2 Changed 12 months ago by
comment:3 Changed 12 months ago by
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).
comment:4 Changed 12 months ago by
 Description modified (diff)
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.
comment:5 Changed 12 months ago by
 Branch set to u/ghmjungmath/add_standard_sphere_to_manifold_catalog
comment:6 followup: ↓ 12 Changed 12 months ago by
 Commit set to bf4440a738f032ad394d0b374e19fd388740cc88
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 nsphere approach

comment:7 Changed 12 months ago by
 Commit changed from bf4440a738f032ad394d0b374e19fd388740cc88 to 3ea0f2738f1137b5a412a80e8b20f395584b883d
Branch pushed to git repo; I updated commit sha1. New commits:
3ea0f27  Trac #30804: transition spher <> stereo added

comment:8 Changed 12 months ago by
comment:9 Changed 12 months ago by
 Commit changed from 3ea0f2738f1137b5a412a80e8b20f395584b883d to 245d563614a030d74b1f67ca3b786254db0b493c
Branch pushed to git repo; I updated commit sha1. New commits:
245d563  Trac #30804: transition maps corrected

comment:10 Changed 12 months ago by
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.
comment:11 Changed 12 months ago by
 Commit changed from 245d563614a030d74b1f67ca3b786254db0b493c to 6215d7937b3b58e465bb8857d396cfe2a5a94752
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
6215d79  Trac #30804: transition spher <> stereo added

comment:12 in reply to: ↑ 6 ; followup: ↓ 13 Changed 12 months ago by
Replying to ghmjungmath:
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. SpringerVerlag, 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^{n} to be the last one (as in (theta, phi) for S^{2}), not the first one.
comment:13 in reply to: ↑ 12 ; followup: ↓ 14 Changed 12 months ago by
Replying to egourgoulhon:
Replying to ghmjungmath:
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. SpringerVerlag, 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^{n} to be the last one (as in (theta, phi) for S^{2}), 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.
comment:14 in reply to: ↑ 13 ; followup: ↓ 15 Changed 12 months ago by
Replying to ghmjungmath:
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^{2} in this example. Then the spherical frame and the stereographic frame from the South pole are righthanded and the stereographic frame from the North pole is lefthanded.
comment:15 in reply to: ↑ 14 Changed 12 months ago by
Replying to egourgoulhon:
Replying to ghmjungmath:
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^{2} in this example. Then the spherical frame and the stereographic frame from the South pole are righthanded and the stereographic frame from the North pole is lefthanded.
That's right. But notice that the convention in the general case is slightly different than in the 2sphere case, compare [1] with [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.
Changed 12 months ago by
comment:16 Changed 12 months ago by
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).
comment:17 Changed 12 months ago by
 Cc ghtobiasdietz added
comment:18 Changed 12 months ago by
 Cc ghtobiasdiez added; ghtobiasdietz removed
comment:19 Changed 12 months ago by
I see these options:
 Keep it the way I suggested.
 Break the convention for the stereographic projection, and put the poles to the first coordinate, then use the convention [1].
 Use suggestion 1 or 2 and separate the 2sphere to obtain convention [2].
 Keep the stereographic convention, alter the convention [1] in such a way that we obtain convention [2] for the 2sphere case.
I personally vote for 1 as long as the documentation is thorough enough.
comment:20 Changed 12 months ago by
 Milestone changed from sage9.2 to sage9.3
comment:21 Changed 12 months ago by
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?
comment:22 followup: ↓ 23 Changed 12 months ago by
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).
comment:23 in reply to: ↑ 22 Changed 12 months ago by
Replying to ghtobiasdiez:
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 nonprimitive working sphere example in any dimension is enough for now.
comment:24 Changed 12 months ago by
 Commit changed from 6215d7937b3b58e465bb8857d396cfe2a5a94752 to 888b360bd2f0e7e49fc1e7939f6d5202ac1916ef
Branch pushed to git repo; I updated commit sha1. New commits:
47600c6  Trac #30804: simplicial complex added

8d2f44d  Trac #30799: collect manifolds examples in 'examples' + lazy_import for catalog

0265e0a  Trac #30804: Merge branch 't/30799/add_folder_for_manifold_models' into t/30804/add_standard_sphere_to_manifold_catalog

d81a522  Trac #30804: "<...>" syntax support for coordinates

60b2724  Merge branch 'develop' into t/30804/add_standard_sphere_to_manifold_catalog

888b360  Trac #30804: coordinate convention in 1D and 2D

comment:25 Changed 12 months ago by
I have added some more features and adapted the coordinates. If you agree on these conventions, I would start with the documentation.
comment:26 Changed 12 months ago by
 Commit changed from 888b360bd2f0e7e49fc1e7939f6d5202ac1916ef to e9c11ddb4451a8543e092b39ac41ee541fb73458
Branch pushed to git repo; I updated commit sha1. New commits:
e9c11dd  Trac #30804: tuple syntax error

comment:27 Changed 12 months ago by
 Commit changed from e9c11ddb4451a8543e092b39ac41ee541fb73458 to ae86b2a90bb5546c147546d3ca66331053bf0ee9
comment:28 Changed 12 months ago by
Okay, this is it, the code should be complete now. I will finish the documentation soon. Until then, you are free to comment on the code.
If everything is done, I will stash the commits to smooth the final merge.
comment:29 Changed 12 months ago by
If you have any ideas for examples that should come up in the documentation, please let me know.
comment:30 followup: ↓ 31 Changed 12 months ago by
This looks very nice. Thanks!
Some first few remarks:
 the reference to Berger should be Geometry II, not Geometry I
 the LaTeX formula in the docstring of
spherical_coordinates
is not correct; in particular, one should have x_n = cos phi_1, not x_n = cos phi_n  could one have an option for the periodic coordinate phi_n to range in [0, 2*pi] instead of [pi, pi]? Both conventions exist in the literature. What should be the default? (I would vote for [0, 2*pi])
 for S^{3}, could we have customized spher. coordinate names (chi, theta, phi) (I think this is pretty standard for S^{3}), instead of (phi_1, phi_2, phi_3)?
 for S^{3}, we should probably have Hopf coordinates as well
comment:31 in reply to: ↑ 30 ; followup: ↓ 33 Changed 12 months ago by
Replying to egourgoulhon:
This looks very nice. Thanks!
Some first few remarks:
 the reference to Berger should be Geometry II, not Geometry I
 the LaTeX formula in the docstring of
spherical_coordinates
is not correct; in particular, one should have x_n = cos phi_1, not x_n = cos phi_n
Corrected. The finished docstring will be pushed soon. Almost done here.
 could one have an option for the periodic coordinate phi_n to range in [0, 2*pi] instead of [pi, pi]? Both conventions exist in the literature. What should be the default? (I would vote for [0, 2*pi])
This belongs more or less to what Tobias suggested. In principle it is good to allow various conventions. However, the case [pi, pi]
is easier to handle with the atan2
function (its range is exactly [pi, pi]
).
 for S^{3}, could we have customized spher. coordinate names (chi, theta, phi) (I think this is pretty standard for S^{3}), instead of (phi_1, phi_2, phi_3)?
I will add them.
 for S^{3}, we should probably have Hopf coordinates as well
I agree. However, I would prefer that the special cases S^1
, S^3
, S^7
are dedicated to a follow up ticket. This ticket already covers all necessary functionalities of general spheres.
comment:32 followup: ↓ 34 Changed 12 months ago by
Moreover, I think it is a splendid idea to connect S^1
and S^3
to its corresponding Lie groups, i.e. U(1)
and SU(2)
, and possible spin groups.
comment:33 in reply to: ↑ 31 ; followup: ↓ 35 Changed 12 months ago by
Replying to ghmjungmath:
Replying to egourgoulhon:
 could one have an option for the periodic coordinate phi_n to range in [0, 2*pi] instead of [pi, pi]? Both conventions exist in the literature. What should be the default? (I would vote for [0, 2*pi])
This belongs more or less to what Tobias suggested. In principle it is good to allow various conventions. However, the case
[pi, pi]
is easier to handle with theatan2
function (its range is exactly[pi, pi]
).
Indeed. Could we have at least a keyword argument periodic_range
in Sphere
? Or do you think this deserves another ticket?
 for S^{3}, we should probably have Hopf coordinates as well
I agree. However, I would prefer that the special cases
S^1
,S^3
,S^7
are dedicated to a follow up ticket. This ticket already covers all necessary functionalities of general spheres.
Agreed.
comment:34 in reply to: ↑ 32 Changed 12 months ago by
Replying to ghmjungmath:
Moreover, I think it is a splendid idea to connect
S^1
andS^3
to its corresponding Lie groups, i.e.U(1)
andSU(2)
, and possible spin groups.
+1
comment:35 in reply to: ↑ 33 Changed 12 months ago by
Replying to egourgoulhon:
Indeed. Could we have at least a keyword argument
periodic_range
inSphere
? Or do you think this deserves another ticket?
Hm, I personally would vote for another ticket. Adding new features would clutter my current progress. I would like to finish the examples and conclude that ticket as soon as possible. Then we can discuss further improvements. My proposal is already more comprehensive than the previous and worth a merge, I'd say.
comment:36 Changed 12 months ago by
 Commit changed from ae86b2a90bb5546c147546d3ca66331053bf0ee9 to 2bb397e1c2e1ea52b923925f75a1422f997943f9
comment:37 Changed 12 months ago by
 Commit changed from 2bb397e1c2e1ea52b923925f75a1422f997943f9 to f3b4d86b415a4cafad1ce495509da89b0cd9f5f3
comment:38 Changed 12 months ago by
docstring should be finished now. Last opportunity to declare wishes for examples.
I will finish everything up tomorrow and set the ticket to needs_review
.
comment:39 Changed 12 months ago by
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.
comment:40 Changed 12 months ago by
You can just set it to needs review now; if there are more comments then people can provide it then.
comment:41 Changed 12 months ago by
 Commit changed from f3b4d86b415a4cafad1ce495509da89b0cd9f5f3 to 95982e80c47b656f94771a8a58bab79f70be6d77
comment:42 Changed 12 months ago by
 Status changed from new to needs_review
Squashed commits. Ready for review.
comment:43 Changed 12 months ago by
comment:44 Changed 12 months ago by
 Commit changed from 95982e80c47b656f94771a8a58bab79f70be6d77 to dfb60450cc477a9bec92c03098f02fb5c607bdc0
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

comment:45 Changed 12 months ago by
 Description modified (diff)
 Summary changed from Add Standard Sphere to Manifold Catalog to Add Spheres smoothly embedded in Euclidean Space to Manifold Catalog
comment:46 Changed 12 months ago by
 Commit changed from dfb60450cc477a9bec92c03098f02fb5c607bdc0 to caa9d5f33b028d3093b1445361f9df95d72d1498
Branch pushed to git repo; I updated commit sha1. New commits:
caa9d5f  Trac #30804: improved orientation example

comment:47 Changed 12 months ago by
Patchbot full green.
comment:48 Changed 12 months ago by
 Reviewers set to Eric Gourgoulhon, Travis Scrimshaw
 Status changed from needs_review to positive_review
Good for me. Travis, do you agree?
comment:49 Changed 12 months ago by
Yep, I agree.
comment:50 followup: ↓ 51 Changed 12 months ago by
Thank you! :)
Eric, would you mind going for the Hopf coordinates?
comment:51 in reply to: ↑ 50 Changed 12 months ago by
Replying to ghmjungmath:
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^{3} 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.
comment:52 Changed 11 months ago by
 Branch changed from u/ghmjungmath/add_standard_sphere_to_manifold_catalog to caa9d5f33b028d3093b1445361f9df95d72d1498
 Resolution set to fixed
 Status changed from positive_review to closed
comment:53 Changed 6 months ago by
 Commit caa9d5f33b028d3093b1445361f9df95d72d1498 deleted
See #31781 for a followup.
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.