Sage: Ticket #31324: Circle doesn't have an orientation
https://trac.sagemath.org/ticket/31324
<p>
The circle S1 with polar coordinates doesn't specify an orientation at the moment. It is also not possible to call <code>set_orientation</code> with the polar chart as argument, since this throws an error that the chart doesn't cover the whole manifold.
</p>
<p>
So I guess to fix this one would need to introduce a set of polar coordinates to get a bona-fide atlas.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/31324
Trac 1.2Eric GourgoulhonWed, 03 Feb 2021 15:57:58 GMT
https://trac.sagemath.org/ticket/31324#comment:1
https://trac.sagemath.org/ticket/31324#comment:1
<p>
Indeed, by default <code>S1</code> is endowed with a single chart and without any orientation:
</p>
<pre class="wiki">sage: S1 = manifolds.Sphere(1)
sage: S1.atlas()
[Chart (A, (phi,))]
sage: S1.orientation()
[]
</pre><p>
I think this is bad; the minimal atlas shall contain enough charts to cover the entire manifold. There is the same issue with all the spheres.
One has to invoke stereographic coordinates to get some orientation:
</p>
<pre class="wiki">sage: S1.stereographic_coordinates()
Chart (S^1-{NP}, (y1,))
sage: S1.atlas()
[Chart (A, (phi,)),
Chart (S^1-{NP}, (y1,)),
Chart (S^1-{SP}, (yp1,)),
Chart (S^1-{NP,SP}, (y1,)),
Chart (S^1-{NP,SP}, (yp1,)),
Chart (A, (y1,)),
Chart (A, (yp1,))]
sage: S1.orientation()
[Coordinate frame (S^1-{SP}, (d/dyp1)), Vector frame (S^1-{NP}, (f_1))]
</pre>
TicketMichael JungWed, 03 Feb 2021 16:32:44 GMT
https://trac.sagemath.org/ticket/31324#comment:2
https://trac.sagemath.org/ticket/31324#comment:2
<p>
This is on purpose! The orientation must cover the entire manifold, otherwise a non-orientable manifold could mistakenly seen as orientable. Take for example the Moebius strip.
</p>
<p>
Polar coordinates do <em>not</em> yield an atlas for S<sup>1, there is a slit missing.
</sup></p>
<p>
So, this behavior is perfectly fine.
</p>
<p>
If you want to use polar coordinates for orientation stuff, you must restrict everything to the open subset <code>A</code>, i.e. <code>S^n</code> without a slit.
</p>
TicketMichael JungWed, 03 Feb 2021 16:35:58 GMT
https://trac.sagemath.org/ticket/31324#comment:3
https://trac.sagemath.org/ticket/31324#comment:3
<p>
As pointed out, to "fix" this (imho this is not a bug), one has to introduce an additional chart which covers the missing slit. This, however, would slow down the initialization of spheres again, especially in higher dimensions, why I would vote against it.
</p>
TicketEric GourgoulhonWed, 03 Feb 2021 16:45:26 GMT
https://trac.sagemath.org/ticket/31324#comment:4
https://trac.sagemath.org/ticket/31324#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:2" title="Comment 2">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This is on purpose! The orientation must cover the entire manifold,
</p>
</blockquote>
<p>
Yes, this is my point. Shouldn't the spheres be initialized with a minimal atlas covering them entirely? At least, for low dimension, due to the CPU cost.
</p>
TicketMichael JungWed, 03 Feb 2021 16:51:59 GMT
https://trac.sagemath.org/ticket/31324#comment:5
https://trac.sagemath.org/ticket/31324#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:4" title="Comment 4">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:2" title="Comment 2">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This is on purpose! The orientation must cover the entire manifold,
</p>
</blockquote>
<p>
Yes, this is my point. Shouldn't the spheres be initialized with a minimal atlas covering them entirely? At least, for low dimension, due to the CPU cost.
</p>
</blockquote>
<p>
Right. But one could argue that the topological data is still there in terms of stereographic coordinates (in contrast to a self-defined manifold with polar coordinates).
</p>
<p>
If one desires a complete atlas at initialization, I'd suggest to introduce some kind of 'lazy atlas' which knows all charts but computes them only on demand. That would be similar to Travis' idea for Grassmannians, see <a class="new ticket" href="https://trac.sagemath.org/ticket/31249" title="#31249: enhancement: Grassmann Manifolds (new)">#31249</a>, and in fact a nice generalization for demanding examples. And similar for the orientation.
</p>
TicketTobias DiezWed, 03 Feb 2021 17:51:16 GMT
https://trac.sagemath.org/ticket/31324#comment:6
https://trac.sagemath.org/ticket/31324#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:2" title="Comment 2">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
This is on purpose! The orientation must cover the entire manifold, otherwise a non-orientable manifold could mistakenly seen as orientable. Take for example the Moebius strip.
</p>
</blockquote>
<p>
Strictly speaking, it suffices to specify the orientation (i.e. a norm-one vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
</p>
<blockquote class="citation">
<p>
Polar coordinates do <em>not</em> yield an atlas for S<sup>1, there is a slit missing.
</sup></p>
</blockquote>
<p>
That's a bit the problem. With the current default atlas, S<sup>1 is diffeomorphic to R, which of course it not correct (or in other words, what is currently returned by S1.atlas is not an atlas of S</sup>1). I cannot say much about the implementation/performance issues, but isn't the transition map to the other polar chart not just a translation by pi?.
</p>
TicketMichael JungWed, 03 Feb 2021 18:06:35 GMT
https://trac.sagemath.org/ticket/31324#comment:7
https://trac.sagemath.org/ticket/31324#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:6" title="Comment 6">gh-tobiasdiez</a>:
</p>
<blockquote class="citation">
<p>
Strictly speaking, it suffices to specify the orientation (i.e. a norm-one vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
</p>
</blockquote>
<p>
The (open) Moebius strip is a counter-example. When you cut the Moebius strip, the cut has measure zero, but the remainder is orientable.
</p>
<blockquote class="citation">
<p>
That's a bit the problem. With the current default atlas, S<sup>1 is diffeomorphic to R, which of course it not correct (or in other words, what is currently returned by S1.atlas is not an atlas of S</sup>1). I cannot say much about the implementation/performance issues, but isn't the transition map to the other polar chart not just a translation by pi?.
</p>
</blockquote>
<p>
That's not true. The polar coordinates are defined only on <code>A</code>, which is a real subset of <code>S^1</code>. <code>A</code> is diffeomorphic to <code>R</code>, <code>S^1</code> is still not.
</p>
TicketEric GourgoulhonWed, 03 Feb 2021 18:30:32 GMT
https://trac.sagemath.org/ticket/31324#comment:8
https://trac.sagemath.org/ticket/31324#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
That's a bit the problem. With the current default atlas, S<sup>1</sup> is diffeomorphic to R, which of course it not correct (or in other words, what is currently returned by S1.atlas is not an atlas of S<sup>1</sup>). I cannot say much about the implementation/performance issues, but isn't the transition map to the other polar chart not just a translation by pi?.
</p>
</blockquote>
<p>
That's not true. The polar coordinates are defined only on <code>A</code>, which is a real subset of <code>S^1</code>. <code>A</code> is diffeomorphic to <code>R</code>, <code>S^1</code> is still not.
</p>
</blockquote>
<p>
Anyway, it would be good, at least for pedagogical purposes, that objects returned by <code>manifolds.Sphere(n)</code> come with a minimal atlas that covers the whole manifold, e.g. an atlas with the two stereographic charts. I understand that there is a performance issue for <code>n</code> large. To circumvent this, we could add an option like <code>complete_atlas=True</code>, so that if some user does not want to construct the stereographic charts and their transition maps when initializing the manifold, he/she could set this option to <code>False</code>.
</p>
TicketTobias DiezWed, 03 Feb 2021 19:51:01 GMT
https://trac.sagemath.org/ticket/31324#comment:9
https://trac.sagemath.org/ticket/31324#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:6" title="Comment 6">gh-tobiasdiez</a>:
</p>
<blockquote class="citation">
<p>
Strictly speaking, it suffices to specify the orientation (i.e. a norm-one vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
</p>
</blockquote>
<p>
The (open) Moebius strip is a counter-example. When you cut the Moebius strip, the cut has measure zero, but the remainder is orientable.
</p>
</blockquote>
<p>
That's only a counterexample to the (wrong) statement that a manifold is orientable iff if it is orientable on dense subset. However, to specify an orientation it is enough to give a unit-norm vector field on a dense subset (such that the vector field extends continuously to the whole manifold).
</p>
TicketMichael JungWed, 03 Feb 2021 22:13:07 GMT
https://trac.sagemath.org/ticket/31324#comment:10
https://trac.sagemath.org/ticket/31324#comment:10
<p>
By the way, what do you mean with "unit-norm vector field". One vector field alone is not enough to determine an orientation, you need an actual frame, i.e. a bunch of point-wise linearly independent vector fields (if you wish they can have unit norm).
</p>
<p>
Even then, the statement seems wrong to me. Assume, your dense set consists of different connected components (for example, make two cuts in the torus). Then you can choose any orientation on each component which might not constitute an orientation on the whole manifold.
</p>
TicketTobias DiezThu, 04 Feb 2021 08:40:13 GMT
https://trac.sagemath.org/ticket/31324#comment:11
https://trac.sagemath.org/ticket/31324#comment:11
<p>
For an orientation you only need to specify what is outward pointing. That's the job of the unit-norm vector field X; the opposite orientation is given by -X.
</p>
<p>
In abstract terms, the orientation bundle is a principal bundle with structure group GL / GL_+ = Z_2. And a continuous section of this bundle is an orientation. This can be a unit-norm vector field or a non-vanishing differential form. Moreover, a continuous map is determined by its values on a dense subset (but of course not every map on a dense subset extends to the whole).
</p>
TicketMichael JungThu, 04 Feb 2021 09:04:21 GMT
https://trac.sagemath.org/ticket/31324#comment:12
https://trac.sagemath.org/ticket/31324#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:11" title="Comment 11">gh-tobiasdiez</a>:
</p>
<blockquote class="citation">
<p>
For an orientation you only need to specify what is outward pointing. That's the job of the unit-norm vector field X; the opposite orientation is given by -X.
</p>
</blockquote>
<p>
If I understand you correctly here, you are talking about submanifolds with codimension 1. But that is a very special case. The implementation of orientations is entirely intrinsic.
</p>
TicketMichael JungThu, 04 Feb 2021 09:06:36 GMT
https://trac.sagemath.org/ticket/31324#comment:13
https://trac.sagemath.org/ticket/31324#comment:13
<p>
And yes, one could use a globally defined (non-vanishing) volume form instead. But that works not on purely topologial manifolds. Besides, at the current stage of implementation, such a form must always be stated in terms of frames, from which we already have to know what orientation they have.
</p>
TicketMichael JungFri, 05 Feb 2021 12:37:52 GMT
https://trac.sagemath.org/ticket/31324#comment:14
https://trac.sagemath.org/ticket/31324#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:8" title="Comment 8">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:7" title="Comment 7">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
That's a bit the problem. With the current default atlas, S<sup>1</sup> is diffeomorphic to R, which of course it not correct (or in other words, what is currently returned by S1.atlas is not an atlas of S<sup>1</sup>). I cannot say much about the implementation/performance issues, but isn't the transition map to the other polar chart not just a translation by pi?.
</p>
</blockquote>
<p>
That's not true. The polar coordinates are defined only on <code>A</code>, which is a real subset of <code>S^1</code>. <code>A</code> is diffeomorphic to <code>R</code>, <code>S^1</code> is still not.
</p>
</blockquote>
<p>
Anyway, it would be good, at least for pedagogical purposes, that objects returned by <code>manifolds.Sphere(n)</code> come with a minimal atlas that covers the whole manifold, e.g. an atlas with the two stereographic charts. I understand that there is a performance issue for <code>n</code> large. To circumvent this, we could add an option like <code>complete_atlas=True</code>, so that if some user does not want to construct the stereographic charts and their transition maps when initializing the manifold, he/she could set this option to <code>False</code>.
</p>
</blockquote>
<p>
For the records, 'large' already means n ≥ 4. I think, the initialization should run fast enough at least for n≤7.
</p>
<p>
The current implementation is, imho, a good compromise between performance and accuracy. Like I said, the topological data is not lost and can easily be retrieved. Besides,
</p>
<pre class="wiki">sage: S1 = manifolds.Sphere(1, coordinates='stereographic')
</pre><p>
initializes the sphere with stereographic coordinates and has therefore the same effect as your suggestion.
</p>
<p>
I don't see a need for a change here; apart from making stereographic coordinates the standard set of charts, but due to performance issues I'd not recommend it.
</p>
<p>
By the way, the intention is not to get the charts by using the atlas but rather calling <code>stereographic_coordinates()</code> etc, which then constructs the charts (and orientation!) on demand.
</p>
<p>
Travis, what do you think?
</p>
TicketMichael JungFri, 05 Feb 2021 13:49:00 GMT
https://trac.sagemath.org/ticket/31324#comment:15
https://trac.sagemath.org/ticket/31324#comment:15
<p>
However, I agree. The least we should do is to document that behavior, i.e. saying that polar coordinates don't constitute a complete atlas.
</p>
TicketTravis ScrimshawSun, 07 Feb 2021 22:17:16 GMT
https://trac.sagemath.org/ticket/31324#comment:16
https://trac.sagemath.org/ticket/31324#comment:16
<p>
S<sup>1</sup> is a bit special since you can use a periodic coordinate chart to uniquely specify the coordinates. So we can special case that (although this technically is not a chart I believe). Otherwise, I think we should document it stating the polar coordinates are not a complete atlas.
</p>
<p>
However, for stereographic coordinates, I would think with knowing all of the formulas explicitly, it shouldn't be too expensive to initialize it. Perhaps you need a mechanism to avoid trying to simplify expressions or something?
</p>
TicketMichael JungSun, 14 Feb 2021 12:51:34 GMT
https://trac.sagemath.org/ticket/31324#comment:17
https://trac.sagemath.org/ticket/31324#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:16" title="Comment 16">tscrim</a>:
</p>
<blockquote class="citation">
<p>
S<sup>1</sup> is a bit special since you can use a periodic coordinate chart to uniquely specify the coordinates. So we can special case that (although this technically is not a chart I believe). Otherwise, I think we should document it stating the polar coordinates are not a complete atlas.
</p>
</blockquote>
<p>
I agree, this should be documented. I'll push some changes here, soon.
</p>
<blockquote class="citation">
<p>
However, for stereographic coordinates, I would think with knowing all of the formulas explicitly, it shouldn't be too expensive to initialize it. Perhaps you need a mechanism to avoid trying to simplify expressions or something?
</p>
</blockquote>
<p>
You are welcome to optimize my code. It's not unlikely that I overlooked potential optimizations.
</p>
TicketMichael JungSun, 14 Feb 2021 13:29:35 GMTstatus changed; branch set
https://trac.sagemath.org/ticket/31324#comment:18
https://trac.sagemath.org/ticket/31324#comment:18
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>branch</strong>
set to <em>public/31324</em>
</li>
</ul>
TicketgitSun, 14 Feb 2021 13:29:58 GMTcommit set
https://trac.sagemath.org/ticket/31324#comment:19
https://trac.sagemath.org/ticket/31324#comment:19
<ul>
<li><strong>commit</strong>
set to <em>e83733d5b6348ed5140c24e80b3cc0fffb3e66c0</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e83733d5b6348ed5140c24e80b3cc0fffb3e66c0"><span class="icon"></span>e83733d</a></td><td><code>Trac #31324: documentation on atlas behavior of spherical coordinates</code>
</td></tr></table>
TicketgitSun, 14 Feb 2021 13:54:20 GMTcommit changed
https://trac.sagemath.org/ticket/31324#comment:20
https://trac.sagemath.org/ticket/31324#comment:20
<ul>
<li><strong>commit</strong>
changed from <em>e83733d5b6348ed5140c24e80b3cc0fffb3e66c0</em> to <em>4358faffec8b28e8fe704558a2bd19b8400ed087</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=4358faffec8b28e8fe704558a2bd19b8400ed087"><span class="icon"></span>4358faf</a></td><td><code>Trac #31324: documentation on atlas behavior of spherical coordinates</code>
</td></tr></table>
TicketMichael JungMon, 15 Feb 2021 09:14:05 GMTauthor set
https://trac.sagemath.org/ticket/31324#comment:21
https://trac.sagemath.org/ticket/31324#comment:21
<ul>
<li><strong>author</strong>
set to <em>Michael Jung</em>
</li>
</ul>
TicketMichael JungMon, 15 Feb 2021 10:14:09 GMT
https://trac.sagemath.org/ticket/31324#comment:22
https://trac.sagemath.org/ticket/31324#comment:22
<p>
For now, I'd say we leave it with a warning. I pushed the changes.
</p>
TicketTravis ScrimshawTue, 16 Feb 2021 04:01:16 GMT
https://trac.sagemath.org/ticket/31324#comment:23
https://trac.sagemath.org/ticket/31324#comment:23
<p>
I think it is worthwhile special-casing the S<sup>1</sup> case since we do have the periodic charts. Is there an argument against this?
</p>
TicketMichael JungTue, 16 Feb 2021 10:30:55 GMT
https://trac.sagemath.org/ticket/31324#comment:24
https://trac.sagemath.org/ticket/31324#comment:24
<p>
Yes, we cannot make an exception for <code>S^1</code> because this requires a complete refactoring of the current orientation code. However, I wouldn't recommend it since orientations must always cover the whole manifold.
</p>
<p>
Alternatively, one could define the domain of the periodic chart being the whole <code>S^1</code>, but that is just mathematically wrong. It would suggest that <code>S^1</code> could be covered by one chart, which is extremely wrong. And since Sage is also used as teaching tool, I would strongly advice against it.
</p>
TicketTravis ScrimshawTue, 16 Feb 2021 23:33:39 GMT
https://trac.sagemath.org/ticket/31324#comment:25
https://trac.sagemath.org/ticket/31324#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:24" title="Comment 24">gh-mjungmath</a>:
</p>
<blockquote class="citation">
<p>
Yes, we cannot make an exception for <code>S^1</code> because this requires a complete refactoring of the current orientation code. However, I wouldn't recommend it since orientations must always cover the whole manifold.
</p>
</blockquote>
<p>
I don't think that is an argument because we can cover S<sup>1</sup> by a single chart with the current implementation, the <em>periodic</em> chart [0, 1). The tricky bit is this is not a chart in the mathematical sense (as far as I am aware), but it is still a single chart here.
</p>
<blockquote class="citation">
<p>
Alternatively, one could define the domain of the periodic chart being the whole <code>S^1</code>, but that is just mathematically wrong. It would suggest that <code>S^1</code> could be covered by one chart, which is extremely wrong. And since Sage is also used as teaching tool, I would strongly advice against it.
</p>
</blockquote>
<p>
As we both seem to agree, this is a problem with the implementation differing from the mathematics. So we need to rectify the two. Implicitly, I believe we are thinking the periodic chart is 2 charts pieced together in a natural way with an implicit orientation. So it would make sense IMO to use that single periodic chart to define the orientation. Otherwise you will need to strip out the abuse, which will make doing research with the code harder and not worth it.
</p>
<p>
S<sup>1</sup> is also special as you don't have to miss 2 points with the polar coordinates, unless you want a disconnected manifold. Because of its special topology compared to higher dimensional spheres, there is plenty of justification for making it behave differently, even if that means returning the stereographic coordinates as the default.
</p>
TicketTobias DiezTue, 16 Feb 2021 23:54:32 GMT
https://trac.sagemath.org/ticket/31324#comment:26
https://trac.sagemath.org/ticket/31324#comment:26
<p>
I'm bit out of the loop, but where is the problem in specifying a correct atlas using two charts in spherical coordinates? So for <code>S^1</code>, on the first chart <code>\phi \in (0, 2 \pi)</code> and on the second chart <code>\phi \in (-\pi, \pi)</code>. This is a proper atlas whose transition function is adding pi. That would be mathematically correct and also easy to implement.
</p>
TicketEric GourgoulhonWed, 17 Feb 2021 08:20:54 GMT
https://trac.sagemath.org/ticket/31324#comment:27
https://trac.sagemath.org/ticket/31324#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:26" title="Comment 26">gh-tobiasdiez</a>:
</p>
<blockquote class="citation">
<p>
I'm bit out of the loop, but where is the problem in specifying a correct atlas using two charts in spherical coordinates? So for <code>S^1</code>, on the first chart <code>\phi \in (0, 2 \pi)</code> and on the second chart <code>\phi \in (-\pi, \pi)</code>. This is a proper atlas whose transition function is adding pi. That would be mathematically correct and also easy to implement.
</p>
</blockquote>
<p>
Yes, this seems the thing to do, probably by introducing a subclass of <code>Sphere</code>. Subclassing <code>Sphere</code> seems required anyway for the parallelisable spheres, i.e. S<sup>1</sup>, S<sup>3</sup> and S<sup>7</sup>.
</p>
TicketMichael JungWed, 17 Feb 2021 08:42:14 GMT
https://trac.sagemath.org/ticket/31324#comment:28
https://trac.sagemath.org/ticket/31324#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/31324#comment:25" title="Comment 25">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Implicitly, I believe we are thinking the periodic chart is 2 charts pieced together...
</p>
</blockquote>
<p>
I like that way of thinking. But that should definitely be made clear to the user. With that argument in mind, I would feel more comfortable to refactor the domain of that chart to the whole sphere for the special case <code>S^1</code> (and then it can be stated as orientation). But clearly saying that this does not give a chart in the mathematical sense, but should rather be thought of two charts glued together. This would also be in line with the examples presented for periodic charts in the charts documentation where the chart covers the whole manifold. In the same instance I would suggest to add a similar comment to the charts documentation where period charts are introduced.
</p>
<blockquote class="citation">
<p>
S<sup>1</sup> is also special as you don't have to miss 2 points with the polar coordinates, unless you want a disconnected manifold. Because of its special topology compared to higher dimensional spheres, there is plenty of justification for making it behave differently, even if that means returning the stereographic coordinates as the default.
</p>
</blockquote>
<p>
Even for higher dimension, you never tear that sphere apart. The missing point just becomes a missing slit. If you allow periodicity, you only miss (the) poles.
</p>
TicketMatthias KöppeMon, 15 Mar 2021 22:07:04 GMTmilestone changed
https://trac.sagemath.org/ticket/31324#comment:29
https://trac.sagemath.org/ticket/31324#comment:29
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.3</em> to <em>sage-9.4</em>
</li>
</ul>
<p>
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
</p>
TicketMatthias KöppeMon, 19 Jul 2021 00:44:56 GMTmilestone changed
https://trac.sagemath.org/ticket/31324#comment:30
https://trac.sagemath.org/ticket/31324#comment:30
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.4</em> to <em>sage-9.5</em>
</li>
</ul>
<p>
Setting a new milestone for this ticket based on a cursory review.
</p>
TicketMichael JungSun, 25 Jul 2021 00:36:07 GMT
https://trac.sagemath.org/ticket/31324#comment:31
https://trac.sagemath.org/ticket/31324#comment:31
<p>
See also <a class="needs_info ticket" href="https://trac.sagemath.org/ticket/31894" title="#31894: enhancement: Refine categories of Chart objects, add method codomain (needs_info)">#31894</a>.
</p>
TicketMatthias KöppeSat, 18 Dec 2021 19:53:12 GMTmilestone changed
https://trac.sagemath.org/ticket/31324#comment:32
https://trac.sagemath.org/ticket/31324#comment:32
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.5</em> to <em>sage-9.6</em>
</li>
</ul>
<p>
Stalled in <code>needs_review</code> or <code>needs_info</code>; likely won't make it into Sage 9.5.
</p>
TicketMatthias KöppeSat, 02 Apr 2022 17:54:54 GMTmilestone changed
https://trac.sagemath.org/ticket/31324#comment:33
https://trac.sagemath.org/ticket/31324#comment:33
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.6</em> to <em>sage-9.7</em>
</li>
</ul>
TicketMatthias KöppeMon, 19 Sep 2022 18:58:47 GMTmilestone changed
https://trac.sagemath.org/ticket/31324#comment:34
https://trac.sagemath.org/ticket/31324#comment:34
<ul>
<li><strong>milestone</strong>
changed from <em>sage-9.7</em> to <em>sage-9.8</em>
</li>
</ul>
Ticket