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: sage-9.5
Component: manifolds Keywords:
Cc: egourgoulhon, tscrim, gh-mjungmath 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:

Status badges

Description (last modified by mkoeppe)

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 non-periodic 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 2-dimensional 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 follow-up tickets.

Change History (54)

comment:1 Changed 5 months ago by mkoeppe

  • Cc egourgoulhon tscrim gh-mjungmath added

comment:2 Changed 5 months ago by mkoeppe

  • Description modified (diff)

comment:3 Changed 5 months ago by mkoeppe

  • Branch set to u/mkoeppe/refine_categories_of_chart_objects__add_method_codomain

comment:4 Changed 5 months ago by mkoeppe

  • Commit set to 759309b90b2ce7d29ecba7f1c0aee1b69f15b5a0

Here is an attempt; but there is a metaclass conflict between Map and UniqueRepresentation that I don't know how to resolve


New commits:

759309bChart: Make it a Map

comment:5 Changed 4 months ago by mkoeppe

  • Dependencies set to #32009

comment:6 Changed 4 months ago by git

  • Commit changed from 759309b90b2ce7d29ecba7f1c0aee1b69f15b5a0 to bd199dc10bb169bacab6519ec361d48238a3b02c

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

5d5e7baChart: Make it a Map
8ba174cEliminate direct use of Chart._domain
e6070fdMerge #32009
bd199dcWIP Chart as a Map

comment:7 Changed 4 months ago by mkoeppe

  • Dependencies changed from #32009 to #31901, #32009

comment:8 Changed 4 months ago by git

  • Commit changed from bd199dc10bb169bacab6519ec361d48238a3b02c to 27433ccca04c6c5ab6c5224fdd5ef78fb0633fa0

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

27433ccChart: Use WithEqualityById

comment:9 Changed 4 months ago by mkoeppe

  • Work issues set to redo on top of #32116

comment:10 Changed 4 months ago by mkoeppe

  • Work issues changed from redo on top of #32116 to redo on top of #32116, #32089

comment:11 Changed 3 months ago by mkoeppe

  • Dependencies changed from #31901, #32009 to #32009, #32116, #32089

comment:12 Changed 3 months ago by mkoeppe

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

  • Commit changed from 27433ccca04c6c5ab6c5224fdd5ef78fb0633fa0 to 9626b54680996ae949d8b1d5b27d45dcc423d075

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

0e63ff1Merge #32116
f66e4bcMerge #32116
7c003dbChart.__init__: Restore default of calc_method argument for consistency
f85e710Chart: in the description of the argument coord_restrictions, replace all instances of 'restrictions' by 'coord_restrictions'
80f6195Chart, RealChart: In class docstring, order arguments as they appear in __classcall__/__init__
a39e6fcDiffChart, RealDiffChart: In class docstring, order arguments as they appear in __classcall__/__init__; add description of argument coord_restrictions
cdf20b0TopologicalManifold.chart: Add description of argument coord_restrictions
741fd2eTopologicalManifold.chart: Add an example of using coord_restrictions
141ccb5Merge #32009
9626b54Merge #32102

comment:14 Changed 3 months ago by git

  • Commit changed from 9626b54680996ae949d8b1d5b27d45dcc423d075 to ce33546fb1bad3ebef7dbbc8a14c83cc583ff320

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

4e7020aTopologicalManifold._Hom_: Handle other categories
ac60cc5Chart._restrict_set: Fix for empty inputs, set/frozenset inputs
ce33546Chart: Make it a Map

comment:15 Changed 3 months ago by mkoeppe

  • Authors set to Matthias Koeppe

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 mkoeppe

  • Description modified (diff)

comment:17 follow-up: Changed 3 months ago by tscrim

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 git

  • Commit changed from ce33546fb1bad3ebef7dbbc8a14c83cc583ff320 to 728c3dfbf01c3e591be6fd3135b3db2d5bc34e00

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

fff2a79src/sage/sets/set.py: Fix docstring markup
1ceafd0Merge #32013
c89c697Merge #32102
451f5cfSets.ParentMethods: Update doctest
f135a05Merge #32015
728c3dfMerge #32089

comment:19 Changed 3 months ago by git

  • Commit changed from 728c3dfbf01c3e591be6fd3135b3db2d5bc34e00 to 9d19b215d003c57160d13ad17b6cef770945b5ee

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

9d19b21Chart, DiffChart: Skip _test_category

comment:20 in reply to: ↑ 17 Changed 3 months ago by mkoeppe

  • Status changed from new to needs_review

Replying to tscrim:

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.

Thanks, that's a simple solution. Ready for review then

comment:21 Changed 3 months ago by git

  • Commit changed from 9d19b215d003c57160d13ad17b6cef770945b5ee to d554f09be4e1c90d14c5da44a23d0523a43afe56

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

d554f09Chart.is_injective, is_surjective, inverse, ...

comment:22 Changed 3 months ago by mkoeppe

  • Status changed from needs_review to needs_work

comment:23 Changed 3 months ago by git

  • Commit changed from d554f09be4e1c90d14c5da44a23d0523a43afe56 to 243fcfda7112c8372e2cbfab058aba5335b0aff5

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

acdb6a7Chart, ChartInverse._call_
243fcfdPeriodic charts as sections

comment:24 Changed 3 months ago by gh-mjungmath

Why is a periodic chart considered non-surjective 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 mkoeppe

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 bijective ChartInverse 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, and Chart is a section map of the ChartInverse.

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.

Last edited 3 months ago by mkoeppe (previous) (diff)

comment:26 Changed 3 months ago by git

  • Commit changed from 243fcfda7112c8372e2cbfab058aba5335b0aff5 to c21f88473d0d45a1bb79ee0d1a8c167a3c80b2c8

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

b76ddd7Chart: Refactor through methods _init_coordinates, _codomain_set; remove _domain attribute
c21f884Chart._codomain_set: Add option periodic_extension, use it to construct the domain of the ChartInverse

comment:27 Changed 3 months ago by mkoeppe

Here's a more complete version of the second variant.

comment:28 Changed 3 months ago by mkoeppe

  • Status changed from needs_work to needs_info

comment:29 follow-up: Changed 3 months ago by gh-mjungmath

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 Rn) are injective but non-surjective.

comment:30 Changed 3 months ago by gh-mjungmath

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 well-defined map.

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

comment:31 Changed 3 months ago by mkoeppe

That's right, there's currently no code to normalize the coordinates

comment:32 follow-up: Changed 3 months ago by mkoeppe

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

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 mkoeppe

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

What about abstract quotients in the spirit of #31644 and/or #31691?

comment:36 Changed 3 months ago by mkoeppe

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 follow-up: Changed 3 months ago by gh-mjungmath

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) half-open intervals? Please correct me if I'm wrong.

comment:38 in reply to: ↑ 29 ; follow-up: Changed 3 months ago by egourgoulhon

Replying to gh-mjungmath:

I like the second variant. It better reflects the situation and what periodic charts actually are.

+1

comment:39 in reply to: ↑ 37 ; follow-ups: Changed 3 months ago by egourgoulhon

Replying to gh-mjungmath:

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 follow-up: Changed 3 months ago by 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.

comment:41 in reply to: ↑ 38 Changed 3 months ago by mkoeppe

Replying to egourgoulhon:

Replying to gh-mjungmath:

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 well-defined (comment:30, comment:31)

comment:42 Changed 3 months ago by mkoeppe

Should ManifoldPoint.add_coordinates canonicalize the coordinates? Or should ManifoldPoint.coordinates do this?

comment:43 in reply to: ↑ 39 Changed 3 months ago by gh-mjungmath

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

comment:44 Changed 3 months ago by gh-mjungmath

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

comment:45 in reply to: ↑ 40 ; follow-up: Changed 3 months ago by gh-mjungmath

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

Just forget what I just said. It didn't make sense. Sorry.

comment:47 in reply to: ↑ 39 ; follow-up: Changed 3 months ago by gh-mjungmath

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 1-sphere this could be for example the clopen interval [-pi,pi). Then it becomes clear that the point on the 1-sphere 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?

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

comment:48 in reply to: ↑ 47 Changed 3 months ago by mkoeppe

Replying to gh-mjungmath:

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 mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5

Setting a new milestone for this ticket based on a cursory review.

comment:50 Changed 3 months ago by git

  • Commit changed from c21f88473d0d45a1bb79ee0d1a8c167a3c80b2c8 to 89039b2f942e8751bbd3722c0a2b7449214e664e

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

ea08261Merge #32009
3d1c44dMerge tag '9.4.beta5' into t/32116/chart__parse_coordinates
cf3abdaMerge #32116
c218828Merge #32116
89039b2Merge #32102

comment:51 in reply to: ↑ 45 ; follow-ups: Changed 3 months ago by egourgoulhon

Replying to gh-mjungmath:

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

I guess then, this ticket depends on #25644...

comment:53 Changed 3 months ago by gh-mjungmath

  • Dependencies changed from #32009, #32116, #32089, #32102 to #32009, #32116, #32089, #32102, #25644

comment:54 in reply to: ↑ 51 Changed 3 months ago by gh-mjungmath

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

Note: See TracTickets for help on using tickets.