Opened 20 months ago
Last modified 2 weeks ago
#31324 needs_review enhancement
Circle doesn't have an orientation
Reported by:  Tobias Diez  Owned by:  

Priority:  major  Milestone:  sage9.8 
Component:  manifolds  Keywords:  
Cc:  Travis Scrimshaw, Nicolas M. Thiéry, Michael Jung, Eric Gourgoulhon, Matthias Köppe  Merged in:  
Authors:  Michael Jung  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  public/31324 (Commits, GitHub, GitLab)  Commit:  4358faffec8b28e8fe704558a2bd19b8400ed087 
Dependencies:  Stopgaps: 
Description
The circle S1 with polar coordinates doesn't specify an orientation at the moment. It is also not possible to call set_orientation
with the polar chart as argument, since this throws an error that the chart doesn't cover the whole manifold.
So I guess to fix this one would need to introduce a set of polar coordinates to get a bonafide atlas.
Change History (34)
comment:1 Changed 20 months ago by
comment:2 followups: 4 6 Changed 20 months ago by
This is on purpose! The orientation must cover the entire manifold, otherwise a nonorientable manifold could mistakenly seen as orientable. Take for example the Moebius strip.
Polar coordinates do not yield an atlas for S^{1, there is a slit missing. }
So, this behavior is perfectly fine.
If you want to use polar coordinates for orientation stuff, you must restrict everything to the open subset A
, i.e. S^n
without a slit.
comment:3 Changed 20 months ago by
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.
comment:4 followup: 5 Changed 20 months ago by
Replying to ghmjungmath:
This is on purpose! The orientation must cover the entire manifold,
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.
comment:5 Changed 20 months ago by
Replying to egourgoulhon:
Replying to ghmjungmath:
This is on purpose! The orientation must cover the entire manifold,
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.
Right. But one could argue that the topological data is still there in terms of stereographic coordinates (in contrast to a selfdefined manifold with polar coordinates).
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 #31249, and in fact a nice generalization for demanding examples. And similar for the orientation.
comment:6 followup: 7 Changed 20 months ago by
Replying to ghmjungmath:
This is on purpose! The orientation must cover the entire manifold, otherwise a nonorientable manifold could mistakenly seen as orientable. Take for example the Moebius strip.
Strictly speaking, it suffices to specify the orientation (i.e. a normone vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
Polar coordinates do not yield an atlas for S^{1, there is a slit missing. }
That's a bit the problem. With the current default atlas, S^{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}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?.
comment:7 followups: 8 9 Changed 20 months ago by
Replying to ghtobiasdiez:
Strictly speaking, it suffices to specify the orientation (i.e. a normone vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
The (open) Moebius strip is a counterexample. When you cut the Moebius strip, the cut has measure zero, but the remainder is orientable.
That's a bit the problem. With the current default atlas, S^{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}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?.
That's not true. The polar coordinates are defined only on A
, which is a real subset of S^1
. A
is diffeomorphic to R
, S^1
is still not.
comment:8 followup: 14 Changed 20 months ago by
Replying to ghmjungmath:
That's a bit the problem. With the current default atlas, S^{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^{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?.
That's not true. The polar coordinates are defined only on
A
, which is a real subset ofS^1
.A
is diffeomorphic toR
,S^1
is still not.
Anyway, it would be good, at least for pedagogical purposes, that objects returned by manifolds.Sphere(n)
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 n
large. To circumvent this, we could add an option like complete_atlas=True
, 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 False
.
comment:9 Changed 20 months ago by
Replying to ghmjungmath:
Replying to ghtobiasdiez:
Strictly speaking, it suffices to specify the orientation (i.e. a normone vector field) only on a dense subspace. But I guess it's probably impossible to check if a subset is dense in sage.
The (open) Moebius strip is a counterexample. When you cut the Moebius strip, the cut has measure zero, but the remainder is orientable.
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 unitnorm vector field on a dense subset (such that the vector field extends continuously to the whole manifold).
comment:10 Changed 20 months ago by
By the way, what do you mean with "unitnorm vector field". One vector field alone is not enough to determine an orientation, you need an actual frame, i.e. a bunch of pointwise linearly independent vector fields (if you wish they can have unit norm).
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.
comment:11 Changed 20 months ago by
For an orientation you only need to specify what is outward pointing. That's the job of the unitnorm vector field X; the opposite orientation is given by X.
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 unitnorm vector field or a nonvanishing 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).
comment:12 Changed 20 months ago by
Replying to ghtobiasdiez:
For an orientation you only need to specify what is outward pointing. That's the job of the unitnorm vector field X; the opposite orientation is given by X.
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.
comment:13 Changed 20 months ago by
And yes, one could use a globally defined (nonvanishing) 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 have to know what orientation they have.
comment:14 Changed 20 months ago by
Replying to egourgoulhon:
Replying to ghmjungmath:
That's a bit the problem. With the current default atlas, S^{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^{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?.
That's not true. The polar coordinates are defined only on
A
, which is a real subset ofS^1
.A
is diffeomorphic toR
,S^1
is still not.Anyway, it would be good, at least for pedagogical purposes, that objects returned by
manifolds.Sphere(n)
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 forn
large. To circumvent this, we could add an option likecomplete_atlas=True
, 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 toFalse
.
For the records, 'large' already means n ≥ 4. I think, the initialization should run fast enough at least for n≤7.
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,
sage: S1 = manifolds.Sphere(1, coordinates='stereographic')
initializes the sphere with stereographic coordinates and has therefore the same effect as your suggestion.
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.
By the way, the intention is not to get the charts by using the atlas but rather calling stereographic_coordinates()
etc, which then constructs the charts (and orientation!) on demand.
Travis, what do you think?
comment:15 Changed 20 months ago by
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.
comment:16 followup: 17 Changed 20 months ago by
S^{1} 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.
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?
comment:17 Changed 20 months ago by
Replying to tscrim:
S^{1} 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.
I agree, this should be documented. I'll push some changes here, soon.
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?
You are welcome to optimize my code. It's not unlikely that I overlooked potential optimizations.
comment:18 Changed 20 months ago by
Branch:  → public/31324 

Status:  new → needs_review 
comment:19 Changed 20 months ago by
Commit:  → e83733d5b6348ed5140c24e80b3cc0fffb3e66c0 

Branch pushed to git repo; I updated commit sha1. New commits:
e83733d  Trac #31324: documentation on atlas behavior of spherical coordinates

comment:20 Changed 20 months ago by
Commit:  e83733d5b6348ed5140c24e80b3cc0fffb3e66c0 → 4358faffec8b28e8fe704558a2bd19b8400ed087 

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
4358faf  Trac #31324: documentation on atlas behavior of spherical coordinates

comment:21 Changed 20 months ago by
Authors:  → Michael Jung 

comment:22 Changed 20 months ago by
For now, I'd say we leave it with a warning. I pushed the changes.
comment:23 Changed 20 months ago by
I think it is worthwhile specialcasing the S^{1} case since we do have the periodic charts. Is there an argument against this?
comment:24 followup: 25 Changed 20 months ago by
Yes, we cannot make an exception for S^1
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.
Alternatively, one could define the domain of the periodic chart being the whole S^1
, but that is just mathematically wrong. It would suggest that S^1
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.
comment:25 followup: 28 Changed 20 months ago by
Replying to ghmjungmath:
Yes, we cannot make an exception for
S^1
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.
I don't think that is an argument because we can cover S^{1} by a single chart with the current implementation, the periodic 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.
Alternatively, one could define the domain of the periodic chart being the whole
S^1
, but that is just mathematically wrong. It would suggest thatS^1
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.
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.
S^{1} 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.
comment:26 followup: 27 Changed 20 months ago by
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 S^1
, on the first chart \phi \in (0, 2 \pi)
and on the second chart \phi \in (\pi, \pi)
. This is a proper atlas whose transition function is adding pi. That would be mathematically correct and also easy to implement.
comment:27 Changed 20 months ago by
Replying to ghtobiasdiez:
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
S^1
, on the first chart\phi \in (0, 2 \pi)
and on the second chart\phi \in (\pi, \pi)
. This is a proper atlas whose transition function is adding pi. That would be mathematically correct and also easy to implement.
Yes, this seems the thing to do, probably by introducing a subclass of Sphere
. Subclassing Sphere
seems required anyway for the parallelisable spheres, i.e. S^{1}, S^{3} and S^{7}.
comment:28 Changed 20 months ago by
Replying to tscrim:
Implicitly, I believe we are thinking the periodic chart is 2 charts pieced together...
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 S^1
(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.
S^{1} 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.
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.
comment:29 Changed 19 months ago by
Milestone:  sage9.3 → sage9.4 

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
comment:30 Changed 15 months ago by
Milestone:  sage9.4 → sage9.5 

Setting a new milestone for this ticket based on a cursory review.
comment:32 Changed 10 months ago by
Milestone:  sage9.5 → sage9.6 

Stalled in needs_review
or needs_info
; likely won't make it into Sage 9.5.
comment:33 Changed 6 months ago by
Milestone:  sage9.6 → sage9.7 

comment:34 Changed 2 weeks ago by
Milestone:  sage9.7 → sage9.8 

Indeed, by default
S1
is endowed with a single chart and without any orientation: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: