Opened 12 months ago

Closed 11 months ago

Last modified 6 months ago

#30804 closed enhancement (fixed)

Add Spheres smoothly embedded in Euclidean Space to Manifold Catalog

Reported by: gh-mjungmath Owned by:
Priority: major Milestone: sage-9.3
Component: manifolds Keywords:
Cc: egourgoulhon, tscrim, gh-tobiasdiez Merged in:
Authors: Michael Jung Reviewers: Eric Gourgoulhon, Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: caa9d5f (Commits, GitHub, GitLab) Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by gh-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

Attachments (1)

spherical.png (693.9 KB) - added by gh-mjungmath 12 months ago.

Download all attachments as: .zip

Change History (54)

comment:1 Changed 12 months ago by gh-mjungmath

  • 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 gh-mjungmath

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.

comment:3 Changed 12 months ago by tscrim

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 gh-mjungmath

  • 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.

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:5 Changed 12 months ago by gh-mjungmath

  • Branch set to u/gh-mjungmath/add_standard_sphere_to_manifold_catalog

comment:6 follow-up: Changed 12 months ago by gh-mjungmath

  • 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:

bf4440aTrac #30804: first n-sphere approach
Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:7 Changed 12 months ago by git

  • Commit changed from bf4440a738f032ad394d0b374e19fd388740cc88 to 3ea0f2738f1137b5a412a80e8b20f395584b883d

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

3ea0f27Trac #30804: transition spher <-> stereo added

comment:8 Changed 12 months ago by gh-mjungmath

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:9 Changed 12 months ago by git

  • Commit changed from 3ea0f2738f1137b5a412a80e8b20f395584b883d to 245d563614a030d74b1f67ca3b786254db0b493c

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

245d563Trac #30804: transition maps corrected

comment:10 Changed 12 months ago by gh-mjungmath

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.

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:11 Changed 12 months ago by git

  • Commit changed from 245d563614a030d74b1f67ca3b786254db0b493c to 6215d7937b3b58e465bb8857d396cfe2a5a94752

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

6215d79Trac #30804: transition spher <-> stereo added

comment:12 in reply to: ↑ 6 ; follow-up: Changed 12 months ago by egourgoulhon

Replying to gh-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 Sn to be the last one (as in (theta, phi) for S2), not the first one.

comment:13 in reply to: ↑ 12 ; follow-up: Changed 12 months ago by gh-mjungmath

Replying to egourgoulhon:

Replying to gh-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 Sn to be the last one (as in (theta, phi) for S2), 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.

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:14 in reply to: ↑ 13 ; follow-up: Changed 12 months ago by egourgoulhon

Replying to gh-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 S2 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.

comment:15 in reply to: ↑ 14 Changed 12 months ago by gh-mjungmath

Replying to egourgoulhon:

Replying to gh-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 S2 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 [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.

Last edited 12 months ago by gh-mjungmath (previous) (diff)

Changed 12 months ago by gh-mjungmath

comment:16 Changed 12 months ago by gh-mjungmath

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).

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:17 Changed 12 months ago by gh-mjungmath

  • Cc gh-tobiasdietz added

comment:18 Changed 12 months ago by gh-mjungmath

  • Cc gh-tobiasdiez added; gh-tobiasdietz removed

comment:19 Changed 12 months ago by gh-mjungmath

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 [1].
  3. Use suggestion 1 or 2 and separate the 2-sphere to obtain convention [2].
  4. Keep the stereographic convention, alter the convention [1] in such a way that we obtain convention [2] for the 2-sphere case.

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

comment:20 Changed 12 months ago by mkoeppe

  • Milestone changed from sage-9.2 to sage-9.3

comment:21 Changed 12 months ago by gh-mjungmath

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?

Last edited 12 months ago by gh-mjungmath (previous) (diff)

comment:22 follow-up: Changed 12 months ago by gh-tobiasdiez

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 gh-mjungmath

Replying to gh-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.

comment:24 Changed 12 months ago by git

  • Commit changed from 6215d7937b3b58e465bb8857d396cfe2a5a94752 to 888b360bd2f0e7e49fc1e7939f6d5202ac1916ef

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

47600c6Trac #30804: simplicial complex added
8d2f44dTrac #30799: collect manifolds examples in 'examples' + lazy_import for catalog
0265e0aTrac #30804: Merge branch 't/30799/add_folder_for_manifold_models' into t/30804/add_standard_sphere_to_manifold_catalog
d81a522Trac #30804: "<...>" syntax support for coordinates
60b2724Merge branch 'develop' into t/30804/add_standard_sphere_to_manifold_catalog
888b360Trac #30804: coordinate convention in 1D and 2D

comment:25 Changed 12 months ago by gh-mjungmath

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 git

  • Commit changed from 888b360bd2f0e7e49fc1e7939f6d5202ac1916ef to e9c11ddb4451a8543e092b39ac41ee541fb73458

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

e9c11ddTrac #30804: tuple syntax error

comment:27 Changed 12 months ago by git

  • Commit changed from e9c11ddb4451a8543e092b39ac41ee541fb73458 to ae86b2a90bb5546c147546d3ca66331053bf0ee9

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

a31fcbbTrac #30804: intermediate commit for docstring
9815ea5Trac #30804: intermediate step
ae86b2aTrac #30804: programming content done

comment:28 Changed 12 months ago by gh-mjungmath

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 gh-mjungmath

If you have any ideas for examples that should come up in the documentation, please let me know.

comment:30 follow-up: Changed 12 months ago by 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
  • 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 S3, could we have customized spher. coordinate names (chi, theta, phi) (I think this is pretty standard for S3), instead of (phi_1, phi_2, phi_3)?
  • for S3, we should probably have Hopf coordinates as well

comment:31 in reply to: ↑ 30 ; follow-up: Changed 12 months ago by gh-mjungmath

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 S3, could we have customized spher. coordinate names (chi, theta, phi) (I think this is pretty standard for S3), instead of (phi_1, phi_2, phi_3)?

I will add them.

  • for S3, 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 follow-up: Changed 12 months ago by gh-mjungmath

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 ; follow-up: Changed 12 months ago by egourgoulhon

Replying to gh-mjungmath:

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 the atan2 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 S3, 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 egourgoulhon

Replying to gh-mjungmath:

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.

+1

comment:35 in reply to: ↑ 33 Changed 12 months ago by gh-mjungmath

Replying to egourgoulhon:

Indeed. Could we have at least a keyword argument periodic_range in Sphere? 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 git

  • Commit changed from ae86b2a90bb5546c147546d3ca66331053bf0ee9 to 2bb397e1c2e1ea52b923925f75a1422f997943f9

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

4497e15Trac #30804: doctests passed so far
2bb397eTrac #30804: next docstring step

comment:37 Changed 12 months ago by git

  • Commit changed from 2bb397e1c2e1ea52b923925f75a1422f997943f9 to f3b4d86b415a4cafad1ce495509da89b0cd9f5f3

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

2a64378Trac #30804: docstring probably finished
f3b4d86Trac #30804: docstring probably finished II

comment:38 Changed 12 months ago by gh-mjungmath

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 gh-mjungmath

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 tscrim

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 git

  • Commit changed from f3b4d86b415a4cafad1ce495509da89b0cd9f5f3 to 95982e80c47b656f94771a8a58bab79f70be6d77

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

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

comment:42 Changed 12 months ago by gh-mjungmath

  • Status changed from new to needs_review

Squashed commits. Ready for review.

comment:43 Changed 12 months ago by gh-mjungmath

  • Authors set to Michael Jung

comment:44 Changed 12 months ago by git

  • Commit changed from 95982e80c47b656f94771a8a58bab79f70be6d77 to dfb60450cc477a9bec92c03098f02fb5c607bdc0

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

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

comment:45 Changed 12 months ago by gh-mjungmath

  • 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 git

  • Commit changed from dfb60450cc477a9bec92c03098f02fb5c607bdc0 to caa9d5f33b028d3093b1445361f9df95d72d1498

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

caa9d5fTrac #30804: improved orientation example

comment:47 Changed 12 months ago by gh-mjungmath

Patchbot full green.

comment:48 Changed 12 months ago by egourgoulhon

  • 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 tscrim

Yep, I agree.

comment:50 follow-up: Changed 12 months ago by gh-mjungmath

Thank you! :)

Eric, would you mind going for the Hopf coordinates?

comment:51 in reply to: ↑ 50 Changed 12 months ago by egourgoulhon

Replying to gh-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 S3 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 vbraun

  • Branch changed from u/gh-mjungmath/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 egourgoulhon

  • Commit caa9d5f33b028d3093b1445361f9df95d72d1498 deleted

See #31781 for a follow-up.

Note: See TracTickets for help on using tickets.