Opened 5 months ago
Last modified 3 months ago
#31894 needs_info enhancement
Refine categories of Chart objects, add method codomain
Reported by:  mkoeppe  Owned by:  

Priority:  major  Milestone:  sage9.5 
Component:  manifolds  Keywords:  
Cc:  egourgoulhon, tscrim, ghmjungmath  Merged in:  
Authors:  Matthias Koeppe  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/mkoeppe/refine_categories_of_chart_objects__add_method_codomain (Commits, GitHub, GitLab)  Commit:  89039b2f942e8751bbd3722c0a2b7449214e664e 
Dependencies:  #32009, #32116, #32089, #32102, #25644  Stopgaps: 
Description (last modified by )
Currently:
sage: M = Manifold(2, 'R^2', structure='topological') sage: c_cart.<x,y> = M.chart() # Cartesian coordinates on R^2 sage: c_cart.category() Category of objects
A Chart
instance (with nonperiodic coordinates) is a continuous map from its domain to R^n
. This should be reflected in the category.
With this ticket:
sage: M = Manifold(2, 'R^2', structure='topological') sage: c_cart.<x,y> = M.chart() # Cartesian coordinates on R^2 sage: c_cart.category() Category of elements of Set of Morphisms from 2dimensional topological manifold R^2 to Vector space of dimension 2 over Real Field with 53 bits of precision in Category of sets
Also:
sage: M = Manifold(2, 'M', field='complex', structure='topological') sage: X.<x,y> = M.chart(coord_restrictions=lambda x,y: [abs(x)<1, y!=0]) sage: X.codomain() { (x, y) ∈ Vector space of dimension 2 over Complex Field with 53 bits of precision : abs(x) < 1, y != 0 }
To put the map in a better category than Sets
will need some followup tickets.
Change History (54)
comment:1 Changed 5 months ago by
 Cc egourgoulhon tscrim ghmjungmath added
comment:2 Changed 5 months ago by
 Description modified (diff)
comment:3 Changed 5 months ago by
 Branch set to u/mkoeppe/refine_categories_of_chart_objects__add_method_codomain
comment:4 Changed 5 months ago by
 Commit set to 759309b90b2ce7d29ecba7f1c0aee1b69f15b5a0
comment:5 Changed 4 months ago by
 Dependencies set to #32009
comment:6 Changed 4 months ago by
 Commit changed from 759309b90b2ce7d29ecba7f1c0aee1b69f15b5a0 to bd199dc10bb169bacab6519ec361d48238a3b02c
comment:7 Changed 4 months ago by
 Dependencies changed from #32009 to #31901, #32009
comment:8 Changed 4 months ago by
 Commit changed from bd199dc10bb169bacab6519ec361d48238a3b02c to 27433ccca04c6c5ab6c5224fdd5ef78fb0633fa0
Branch pushed to git repo; I updated commit sha1. New commits:
27433cc  Chart: Use WithEqualityById

comment:9 Changed 4 months ago by
 Work issues set to redo on top of #32116
comment:10 Changed 4 months ago by
 Work issues changed from redo on top of #32116 to redo on top of #32116, #32089
comment:11 Changed 3 months ago by
 Dependencies changed from #31901, #32009 to #32009, #32116, #32089
comment:12 Changed 3 months ago by
 Dependencies changed from #32009, #32116, #32089 to #32009, #32116, #32089, #32102
 Work issues redo on top of #32116, #32089 deleted
comment:13 Changed 3 months ago by
 Commit changed from 27433ccca04c6c5ab6c5224fdd5ef78fb0633fa0 to 9626b54680996ae949d8b1d5b27d45dcc423d075
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
0e63ff1  Merge #32116

f66e4bc  Merge #32116

7c003db  Chart.__init__: Restore default of calc_method argument for consistency

f85e710  Chart: in the description of the argument coord_restrictions, replace all instances of 'restrictions' by 'coord_restrictions'

80f6195  Chart, RealChart: In class docstring, order arguments as they appear in __classcall__/__init__

a39e6fc  DiffChart, RealDiffChart: In class docstring, order arguments as they appear in __classcall__/__init__; add description of argument coord_restrictions

cdf20b0  TopologicalManifold.chart: Add description of argument coord_restrictions

741fd2e  TopologicalManifold.chart: Add an example of using coord_restrictions

141ccb5  Merge #32009

9626b54  Merge #32102

comment:14 Changed 3 months ago by
 Commit changed from 9626b54680996ae949d8b1d5b27d45dcc423d075 to ce33546fb1bad3ebef7dbbc8a14c83cc583ff320
comment:15 Changed 3 months ago by
This is almost ready, except that a Chart
does not have the correct element class of the Homset, so some _test_category
tests are failing. Help with this would be very welcome.
comment:16 Changed 3 months ago by
 Description modified (diff)
comment:17 followup: ↓ 20 Changed 3 months ago by
We generally skip _test_category
for Homset
subclasses IIRC. They can often have multiple classes that are all elements because we need different implementations based on input types. We currently don't have a good system for dealing with parents with multiple element classes. :/
comment:18 Changed 3 months ago by
 Commit changed from ce33546fb1bad3ebef7dbbc8a14c83cc583ff320 to 728c3dfbf01c3e591be6fd3135b3db2d5bc34e00
comment:19 Changed 3 months ago by
 Commit changed from 728c3dfbf01c3e591be6fd3135b3db2d5bc34e00 to 9d19b215d003c57160d13ad17b6cef770945b5ee
Branch pushed to git repo; I updated commit sha1. New commits:
9d19b21  Chart, DiffChart: Skip _test_category

comment:20 in reply to: ↑ 17 Changed 3 months ago by
 Status changed from new to needs_review
Replying to tscrim:
We generally skip
_test_category
forHomset
subclasses IIRC. They can often have multiple classes that are all elements because we need different implementations based on input types.
Thanks, that's a simple solution. Ready for review then
comment:21 Changed 3 months ago by
 Commit changed from 9d19b215d003c57160d13ad17b6cef770945b5ee to d554f09be4e1c90d14c5da44a23d0523a43afe56
Branch pushed to git repo; I updated commit sha1. New commits:
d554f09  Chart.is_injective, is_surjective, inverse, ...

comment:22 Changed 3 months ago by
 Status changed from needs_review to needs_work
comment:23 Changed 3 months ago by
 Commit changed from d554f09be4e1c90d14c5da44a23d0523a43afe56 to 243fcfda7112c8372e2cbfab058aba5335b0aff5
comment:24 Changed 3 months ago by
Why is a periodic chart considered nonsurjective but injective? Isn't it exactly the opposite?
Besides, Travis suggested that periodic charts could be considered being proper charts but glued together #31324@comment:25. Maybe we can somehow incorporate this here?
comment:25 Changed 3 months ago by
I have two possible variants:
 as of acdb6a7, the codomain of the
Chart
is a fundamental cell of the periodic coordinate space. Presumably the user declares the periodic coordinates in a way that the computed coordinates always lie in the fundamental domain. Corestricted like this, the chart is bijective, with a bijectiveChartInverse
as its inverse. But it does not capture the fact that one is also allowed to use coordinates outside of the fundamental domain to construct a point.
 with 243fcfd + work in progress (not on the branch yet), the
ChartInverse
is a surjection from the full coordinate space to the chart's domain, andChart
is a section map of theChartInverse
.
I don't know which of the two you would find preferable and also cannot speak to Travis' suggestion regarding possible changes to the design.
comment:26 Changed 3 months ago by
 Commit changed from 243fcfda7112c8372e2cbfab058aba5335b0aff5 to c21f88473d0d45a1bb79ee0d1a8c167a3c80b2c8
comment:27 Changed 3 months ago by
Here's a more complete version of the second variant.
comment:28 Changed 3 months ago by
 Status changed from needs_work to needs_info
comment:29 followup: ↓ 38 Changed 3 months ago by
I like the second variant. It better reflects the situation and what periodic charts actually are.
Then it also makes sense that periodic charts (as maps from a manifold subset into a subset of R^{n) are injective but nonsurjective. }
comment:30 Changed 3 months ago by
But then we have to make a choice, right? The current situation is as follows (for example):
sage: S1 = manifolds.Sphere(1) sage: spher = S1.spherical_coordinates() sage: p = S1.point((pi,)) sage: q = S1.point((pi,)) sage: spher(p) (pi,) sage: spher(q) (pi,)
At current stage, this is not a welldefined map.
comment:31 Changed 3 months ago by
That's right, there's currently no code to normalize the coordinates
comment:32 followup: ↓ 33 Changed 3 months ago by
It would all be easier if we had an implementation of RR/ZZ
in Sage...
comment:33 in reply to: ↑ 32 Changed 3 months ago by
Replying to mkoeppe:
It would all be easier if we had an implementation of
RR/ZZ
in Sage...
...or even better topological quotient spaces.
comment:34 Changed 3 months ago by
OK, QQ/ZZ
exists (sage.groups.additive_abelian.qmodnz
), and we also have at least two incompatible implementations of lattices and their quotients in sage.geometry.toric_lattice
and sage.modules.free_module_integer
. Perhaps also something in sage.schemes
somewhere
comment:35 Changed 3 months ago by
comment:36 Changed 3 months ago by
Well, I have #32012 (Quotient of polyhedron or convex set by a lattice) but one has to be careful that things remain concrete enough to be useful, as the main point of the ticket is to make things more "composable".
comment:37 followup: ↓ 39 Changed 3 months ago by
Periodic charts are always defined via (connected) intervals, aren't they? W.l.o.g. we can always choose the minimum/maximum the chart maps to? Alternatively, we can make a chart a bijection onto (cross products of) halfopen intervals? Please correct me if I'm wrong.
comment:38 in reply to: ↑ 29 ; followup: ↓ 41 Changed 3 months ago by
Replying to ghmjungmath:
I like the second variant. It better reflects the situation and what periodic charts actually are.
+1
comment:39 in reply to: ↑ 37 ; followups: ↓ 43 ↓ 47 Changed 3 months ago by
Replying to ghmjungmath:
Periodic charts are always defined via (connected) intervals, aren't they?
Yes I think so.
W.l.o.g. we can always choose the minimum/maximum the chart maps to?
What do you mean?
comment:40 followup: ↓ 45 Changed 3 months ago by
Just a word of context about periodic charts: they have been introduced because they are useful when computing a geodesic with some numerical integrator. Typically, when the geodesic is an orbit around some center, the azimuthal coordinate returned by the integrator increases without any bound, instead of being confined to [0, 2\pi). Here are some examples in Kerr spacetime.
comment:41 in reply to: ↑ 38 Changed 3 months ago by
Replying to egourgoulhon:
Replying to ghmjungmath:
I like the second variant. It better reflects the situation and what periodic charts actually are.
+1
OK, then it just remains to make it welldefined (comment:30, comment:31)
comment:42 Changed 3 months ago by
Should ManifoldPoint.add_coordinates
canonicalize the coordinates?
Or should ManifoldPoint.coordinates
do this?
comment:43 in reply to: ↑ 39 Changed 3 months ago by
comment:44 Changed 3 months ago by
comment:45 in reply to: ↑ 40 ; followup: ↓ 51 Changed 3 months ago by
Replying to egourgoulhon:
Just a word of context about periodic charts: they have been introduced because they are useful when computing a geodesic with some numerical integrator. Typically, when the geodesic is an orbit around some center, the azimuthal coordinate returned by the integrator increases without any bound, instead of being confined to [0, 2\pi). Here are some examples in Kerr spacetime.
I'm sorry. What is the punchline here?
comment:46 Changed 3 months ago by
Just forget what I just said. It didn't make sense. Sorry.
comment:47 in reply to: ↑ 39 ; followup: ↓ 48 Changed 3 months ago by
Replying to egourgoulhon:
W.l.o.g. we can always choose the minimum/maximum the chart maps to?
What do you mean?
What we can do is that the user has to state the fundamental domain (which currently happens up to boundary only). Or we provide which boundary component belongs to the fundamental domain (I opt for the lower bound). Then it is clear which points the section map has to map to.
For the 1sphere this could be for example the clopen interval [pi,pi)
. Then it becomes clear that the point on the 1sphere determined by pi
is mapped to pi
via the (section) chart. Similarly then for any other point.
The only obstruction I see right now is that the symbolic ring doesn't provide any modulo operation in the spirit of x  y*floor(x/y)
. Or does it?
comment:48 in reply to: ↑ 47 Changed 3 months ago by
Replying to ghmjungmath:
the symbolic ring doesn't provide any modulo operation in the spirit of
x  y*floor(x/y)
.
That's right  this is #25644
comment:49 Changed 3 months ago by
 Milestone changed from sage9.4 to sage9.5
Setting a new milestone for this ticket based on a cursory review.
comment:50 Changed 3 months ago by
 Commit changed from c21f88473d0d45a1bb79ee0d1a8c167a3c80b2c8 to 89039b2f942e8751bbd3722c0a2b7449214e664e
comment:51 in reply to: ↑ 45 ; followups: ↓ 52 ↓ 54 Changed 3 months ago by
Replying to ghmjungmath:
Replying to egourgoulhon:
Just a word of context about periodic charts: they have been introduced because they are useful when computing a geodesic with some numerical integrator. Typically, when the geodesic is an orbit around some center, the azimuthal coordinate returned by the integrator increases without any bound, instead of being confined to [0, 2\pi). Here are some examples in Kerr spacetime.
I'm sorry. What is the punchline here?
Periodic charts are useful in practice. Otherwise, we could have lived without them, sticking to the standard definition of a chart on a manifold.
comment:52 in reply to: ↑ 51 Changed 3 months ago by
I guess then, this ticket depends on #25644...
comment:53 Changed 3 months ago by
 Dependencies changed from #32009, #32116, #32089, #32102 to #32009, #32116, #32089, #32102, #25644
comment:54 in reply to: ↑ 51 Changed 3 months ago by
Replying to egourgoulhon:
I'm sorry. What is the punchline here?
Periodic charts are useful in practice. Otherwise, we could have lived without them, sticking to the standard definition of a chart on a manifold.
Thank you. It's clear now. It was my fault yesterday...
Here is an attempt; but there is a metaclass conflict between
Map
andUniqueRepresentation
that I don't know how to resolveNew commits:
Chart: Make it a Map