Implement categories for topological and metric spaces and related categories

[tscrim]

After a discussion at Sage Days 64, we decided to implement a variety of categories pertaining to geometry and topology to lend assistance to SageManifolds (#18528) and to generalize idioms in the hyperbolic geometry (#9439). This implements the following categories:

• topological spaces
• metric spaces
• manifolds
• CW complexes
• simplicial complexes (which has been needed, see Morphisms and Objects of Categories #10667, morphisms of simplicial complexes and the associated chain complex morphisms #6099)
• Lie groups

and axioms:

• complete
• compact
• analytic
• differentiable
• smooth
• almost complex

Depends on #18174
Depends on #17160

CC: @nthiery @egourgoulhon

Component: categories

Keywords: topology, sd67

Author: Travis Scrimshaw

Branch/Commit: f6fdd7d

Reviewer: Eric Gourgoulhon

Issue created by migration from https://trac.sagemath.org/ticket/18175

[tscrim]

Branch: public/categories/topological_metric_spaces-18175

[tscrim]

comment:1

I've implemented a bunch of stub categories as an overall layout guide. My method stubs and documentation will need to be expanded upon, including adding (more) tests, along with lifting methods from the hyperbolic geometry module. There is currently an abuse of Finite for CW complexes as they are not typically finite as sets (in fact, the only finite CW complexes are a finite collection of 0-cells), but the terminology is finite CW complex meaning a finite number of cells.

Eric, hopefully this is enough to get you started on what you'd want/need for SageManifolds. I probably won't work much more on this for a while.

---

New commits:

77b801c	Inital stubs
0e78e25	Implement generic functorial construction base class magic.
96547d2	Merge branch 'public/categories/functorial_magic-18174' into public/categories/topological_metric_spaces-TBA
bdb08fb	Some cleanup and getting category stubs ready.
68b85e9	Adding some more stubs for categories.

[tscrim]

Commit: 68b85e9

[tscrim]

Dependencies: #18174

[sagetrac-git]

Changed commit from 68b85e9 to aea3a7d

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:

cf9b429	Fixed ReST typo
aff2689	17160: fixed category for finite set endomaps + minor `__init__` refactoring
4b3d74c	Merge branch 'develop' into categories/finitely-generated-magmas-17160
ad5d6c0	8678: permutation groups are finitely generated, finite fields are enumerated, fixes
839200e	8678: More doctest updates. Should almost pass all tests.
919a215	Merge branch 'develop = sage 6.6 beta6' into categories/finitely-generated-magmas-17160
ef01ef0	Merge branch 't/18012/sphinx_depends_on_jinja2' into categories/finitely-generated-magmas-17160
975c008	Merge branch 'u/nthiery/categories/finitely-generated-magmas-17160' of trac.sagemath.org:sage into categories/finitely-generated-magmas-17160
19ceb81	Merge branch 'u/nthiery/categories/finitely-generated-magmas-17160' of trac.sagemath.org:sage into public/categories/finitely_generated_magma-17160
aea3a7d	Merge branch 'public/categories/finitely_generated_magma-17160' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175

[tscrim]

Changed dependencies from #18174 to #18174 #17160

[tscrim]

comment:4

Handled conflicts with #17160.

[egourgoulhon]

comment:5

Hi Travis,

Replying to @tscrim:

Eric, hopefully this is enough to get you started on what you'd want/need for SageManifolds. I probably won't work much more on this for a while.

That's great! Many thanks for implementing this. In a week or two, I'll start to split SageManifolds in small tickets and will of course use your category framework.

Eric.

[nthiery]

Changed keywords from topology to topology, sd67

[egourgoulhon]

comment:7

Hi Travis,

I gave a look at the category Manifolds; it looks nice and I have the following comments:

• the methods dimension() and FiniteDimensional(), and well as the class FiniteDimensional, are defined only at the level of Connected; shouldn't they be at the level of Manifolds itself ?
• in the docstring of Manifolds, I think the phrase "such that the neighborhood of any point x \in M is homeomorphic to k^d" should be changed to something like "such that any point x\in M admits a neighborhood homeomorphic to k^d"

Eric.

[tscrim]

comment:8

Replying to @egourgoulhon:

• the methods dimension() and FiniteDimensional(), and well as the class FiniteDimensional, are defined only at the level of Connected; shouldn't they be at the level of Manifolds itself ?

I wasn't sure about the dimension making sense for manifolds unless they are connected as far as my definition. Mainly do we want the disjoint union of a 1-sphere and 2-sphere be a manifold? (Current definition is yes). If so, then is the dimension the maximal dimension of each component? I will leave the decision up to you.

• in the docstring of Manifolds, I think the phrase "such that the neighborhood of any point x \in M is homeomorphic to k^d" should be changed to something like "such that any point x\in M admits a neighborhood homeomorphic to k^d"

Feel free to change the docstrings and categories as much as you want. However if you just want to get these category stubs into Sage as a smaller step, we can do that too.

[egourgoulhon]

comment:9

Replying to @tscrim:

Replying to @egourgoulhon:

• the methods dimension() and FiniteDimensional(), and well as the class FiniteDimensional, are defined only at the level of Connected; shouldn't they be at the level of Manifolds itself ?

I wasn't sure about the dimension making sense for manifolds unless they are connected as far as my definition. Mainly do we want the disjoint union of a 1-sphere and 2-sphere be a manifold? (Current definition is yes). If so, then is the dimension the maximal dimension of each component? I will leave the decision up to you.

For all the textbook definitions I am aware of, the disjoint union of a 1-sphere and a 2-sphere is not a manifold. In other words, the dimension is unique among all the connected components of the manifold. So I think the dimension should be at the level of Manifolds.

• in the docstring of Manifolds, I think the phrase "such that the neighborhood of any point x \in M is homeomorphic to k^d" should be changed to something like "such that any point x\in M admits a neighborhood homeomorphic to k^d"

Feel free to change the docstrings and categories as much as you want. However if you just want to get these category stubs into Sage as a smaller step, we can do that too.

Apart from the dimension issue discussed above, the current categories seems fine to rebase SageManifolds on them, thanks. I'll try soon and let you know.

[sagetrac-git]

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

349fe0f	Merge branch 'public/categories/topological_metric_spaces-18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175
fcc3273	Move dim to all manifolds, move methods from H-plane to metric spaces, some fixes.

[sagetrac-git]

Changed commit from aea3a7d to fcc3273

[tscrim]

comment:11

Replying to @egourgoulhon:

Replying to @tscrim:

I wasn't sure about the dimension making sense for manifolds unless they are connected as far as my definition. Mainly do we want the disjoint union of a 1-sphere and 2-sphere be a manifold? (Current definition is yes). If so, then is the dimension the maximal dimension of each component? I will leave the decision up to you.

For all the textbook definitions I am aware of, the disjoint union of a 1-sphere and a 2-sphere is not a manifold. In other words, the dimension is unique among all the connected components of the manifold. So I think the dimension should be at the level of Manifolds.

I split the difference in that I kept a more general definition, but I had dimension be the maximum of the dimensions of each connected component so you don't necessarily have to specify connected.

• in the docstring of Manifolds, I think the phrase "such that the neighborhood of any point x \in M is homeomorphic to k^d" should be changed to something like "such that any point x\in M admits a neighborhood homeomorphic to k^d"

Feel free to change the docstrings and categories as much as you want. However if you just want to get these category stubs into Sage as a smaller step, we can do that too.

Apart from the dimension issue discussed above, the current categories seems fine to rebase SageManifolds on them, thanks. I'll try soon and let you know.

I made some fixes, specifically I stopped an infinite recursion with metric spaces caused by some of my last-minute refactoring. I forgot to make the other change to the manifold's doc, but I want to make sure you're okay with my definition of a manifold before I keep changing it. This is almost ready for review up to some methods not containing doctests.

[egourgoulhon]

comment:12

Replying to @tscrim:

Replying to @egourgoulhon:

Replying to @tscrim:

I wasn't sure about the dimension making sense for manifolds unless they are connected as far as my definition. Mainly do we want the disjoint union of a 1-sphere and 2-sphere be a manifold? (Current definition is yes). If so, then is the dimension the maximal dimension of each component? I will leave the decision up to you.

For all the textbook definitions I am aware of, the disjoint union of a 1-sphere and a 2-sphere is not a manifold. In other words, the dimension is unique among all the connected components of the manifold. So I think the dimension should be at the level of Manifolds.

I split the difference in that I kept a more general definition, but I had dimension be the maximum of the dimensions of each connected component so you don't necessarily have to specify connected.

Do you have a reference for such a definition of a manifold ? It seems non-standard () to me, but I might be wrong.
() the standard being that the dimension is the same for all the connected components.

[sagetrac-git]

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

5796cbd

Merge branch 'public/categories/topological_metric_spaces-18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175

[sagetrac-git]

Changed commit from fcc3273 to 5796cbd

[tscrim]

comment:14

On Wikipedia (http://en.wikipedia.org/wiki/Dimension), they are careful to say a connected manifold. I do agree with you that the standard definition, but the usual case only considers connected manifolds. I did find some papers which don't assume each component has the same dimension, but I can't find them in minute I have to write this. I will look later though. For this, I wanted to be general and consistent with CW complexes. I think SageManifolds can create connected components with different dimension, but I haven't tried.

[egourgoulhon]

comment:15

Replying to @tscrim:

On Wikipedia (http://en.wikipedia.org/wiki/Dimension), they are careful to say a connected manifold.

Yes. I've looked a little further and found that some authors do allow for different dimensions on different connected components; they then define a pure manifold as a manifold for which the dimension is the same among all connected components. On the other side, other authors refuse to do this: for instance, J.M. Lee, in his Introduction to Topological Manifolds (2nd ed., 2011) says on p. 39: "the first remark is that the definition of a manifold requires that every manifold have a specific, well-defined dimension. This rules out, for example, spaces such as a disjoint union of a line and a plane in R³ ".
Since there is no consensus in the literature, it's fine to take either definition, as long as it is clearly stated. I therefore agree with your definition, especially since it is consistent with CW complexes.

[jhpalmieri]

comment:16

My professional opinion as a topologist is that a manifold should have a well-defined dimension n, and every point of that manifold should have a neighborhood homeomorphic to Rⁿ. So even if it's not connected, the different components should have the same dimension.

I think that more people would be unpleasantly surprised if we allowed different components to have different dimensions than if we had the more relaxed version. (There is no similar discomfort for CW complexes or simplicial complexes: topologists are perfectly happy having a CW complex with maximal cells of different dimensions.)

[egourgoulhon]

comment:53

Some doctests are still failing:
sage -t --long src/sage/categories/morphism.pyx # 1 doctest failed
sage -t --long src/sage/rings/rational_field.py # 1 doctest failed
sage -t --long src/sage/misc/functional.py # 1 doctest failed
sage -t --long src/sage/algebras/clifford_algebra.py # 1 doctest failed

[nthiery]

comment:54

Replying to @tscrim:

@nthiery Note that I had to make a change to the French Sage book's test.

I double checked it, and it's fine with me!

[sagetrac-git]

Changed commit from 375ff46 to f8f5b93

[sagetrac-git]

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

8b851a0	Merge branch 'develop' into public/categories/topological_metric_spaces-18175
f8f5b93	Fixing last remaining doctests.

[egourgoulhon]

comment:56

Thanks for the new version. Two remarks:

1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?

2/ The p-adic fields implemented in Sage seems not to have been taken into account:

sage: Qp(5) in Fields().Topological()
False
sage: Qp(5) in Fields().Metric()
False

One should actually have

sage: Qp(5) in Fields().Metric().Complete()
True

There could be other metric fields in Sage, or more generally topological rings, that should be included. But maybe this is too much work for this ticket and should be delayed to some subsequent ticket ?

[sagetrac-git]

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

041a5d1

Adding p-adics to metric spaces and some cleanup.

[sagetrac-git]

Changed commit from f8f5b93 to 041a5d1

[tscrim]

comment:58

Replying to @egourgoulhon:

1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?

Yes they should and now they do.

2/ The p-adic fields implemented in Sage seems not to have been taken into account:

sage: Qp(5) in Fields().Topological()
False
sage: Qp(5) in Fields().Metric()
False

One should actually have

sage: Qp(5) in Fields().Metric().Complete()
True

There could be other metric fields in Sage, or more generally topological rings, that should be included. But maybe this is too much work for this ticket and should be delayed to some subsequent ticket ?

I've added them in and I reworked the default dist to use the abs method of the elements. I also made it so that there is a call loop P.metric -> E.dist -> P.dist -> E.abs -> P.metric so one just needs to implement one of these methods (P is the parent and E is the element). This is a slight abuse as not all metric spaces have a 0 (more generally a distinguished base point), nor implement subtraction. I think this is something we can live with for now and on a followup ticket better refine the categories for these generic metrics as most parents who additive groups (well, this might be a stronger condition than needed, but I'm not worrying about that now). I also really don't want to go back through Sage and make all those trivial category changes again...

[sagetrac-git]

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

bfa0cdf

One last doc tweak.

[sagetrac-git]

Changed commit from 041a5d1 to bfa0cdf

[sagetrac-git]

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

d13c368

Fixing doc of metric spaces.

[sagetrac-git]

Changed commit from bfa0cdf to d13c368

[egourgoulhon]

comment:61

Replying to @tscrim:

Replying to @egourgoulhon:

1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?

Yes they should and now they do.

Very good.

I've added them in and I reworked the default dist to use the abs method of the elements. I also made it so that there is a call loop P.metric -> E.dist -> P.dist -> E.abs -> P.metric so one just needs to implement one of these methods (P is the parent and E is the element). This is a slight abuse as not all metric spaces have a 0 (more generally a distinguished base point), nor implement subtraction. I think this is something we can live with for now and on a followup ticket better refine the categories for these generic metrics as most parents who additive groups (well, this might be a stronger condition than needed, but I'm not worrying about that now).

The default dist using abs seems reasonable at this stage. Thanks for having added the p-adic fields.

I've merged the last commit of this ticket in all the tickets of #18528, replacing the Sets() category by Manifolds(K), Manifolds(K).Differentiable() or Manifolds(K).Smooth(), with K=RR, QQ, Qp(5) or CC. Everything works well!

I've just one last question:

In the examples (in src/sage/categories/examples/manifolds.py and src/sage/categories/examples/cw_complexes.py), the parents implement the method an_element and not _an_element_ (as advised in the Parent section of the reference manual). Is there any reason for this?

and three suggestions of typo corrections:

• in src/sage/categories/manifolds.py, line 70: replace
  "a morphism of metric spaces between manifolds is a manifold morphism" by
  "a morphism of topological spaces between manifolds is a manifold morphism"
• in src/sage/categories/metric_spaces.py, line 48: replace "is simultaneously a
  topological group by itself, and a topogological space"
  by "is simultaneously a topological group by itself, and a metric space"
• in src/sage/categories/topological_spaces.py, there seems to be an unnecessary import:
  from sage.misc.lazy_attribute import lazy_class_attribute

[sagetrac-git]

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

f6fdd7d

Some last little bit of cleanup.

[sagetrac-git]

Changed commit from d13c368 to f6fdd7d

[tscrim]

comment:63

Replying to @egourgoulhon:

I've merged the last commit of this ticket in all the tickets of #18528, replacing the Sets() category by Manifolds(K), Manifolds(K).Differentiable() or Manifolds(K).Smooth(), with K=RR, QQ, Qp(5) or CC. Everything works well!

That's very good to hear!

I've just one last question:

In the examples (in src/sage/categories/examples/manifolds.py and src/sage/categories/examples/cw_complexes.py), the parents implement the method an_element and not _an_element_ (as advised in the Parent section of the reference manual). Is there any reason for this?

The reason we have _an_element_ was for caching before there was an @cached_method. It is sufficient to implement an_element, especially for example classes. However, I can change if it you feel I should.

and three suggestions of typo corrections

All done (and some other pyflakes cleanup).

[egourgoulhon]

comment:64

Replying to @tscrim:

The reason we have _an_element_ was for caching before there was an @cached_method. It is sufficient to implement an_element, especially for example classes. However, I can change if it you feel I should.

No not at all; I was just curious. Thanks for the explanation.

and three suggestions of typo corrections

All done (and some other pyflakes cleanup).

Thank you for your work ! It's nice to have these categories.

[tscrim]

comment:65

Thanks for doing the review.

[vbraun]

Changed branch from public/categories/topological_metric_spaces-18175 to f6fdd7d