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 #10667, #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

[egourgoulhon]

comment:41

Replying to @tscrim:

Just to make sure, so should we only allow complete metric fields as input for differentiable manifolds? The alternative seems to be we allow more general topological fields with perhaps some machinery to make analytic manifolds over finite fields be non-smooth. Let me know what you think is best.

I would favor the second alternative, i.e. not to restrict to complete metric fields. In particular, there are some attempts to define differentiable manifolds over general topological fields, see e.g. math/0502168. Basile, John, Nicolas, do you agree ?

PS: even if we don't demand that the base fields for differentiable manifolds are complete metric spaces, it would be nice to have an axiom "complete" for the category of metric spaces, as you suggest in comment:39.

[tscrim]

comment:42

ping

For the record, I'm okay with general topological fields.

[egourgoulhon]

comment:43

Hi Travis, Sorry for the delay. If you agree with general topological fields (non-discrete to define differentiable manifolds, I guess), then the hierarchy should be similar to that suggested in comment:28, namely:

   Manifolds
      | 
 Differentiable
      |
    Smooth
      |
   Analytic

leaving the base field generic. Then Real or Complex could be added at any level (as axioms ?) (actually for complex, differentiable implies analytic). What do you think?

[egourgoulhon]

Reviewer: Eric Gourgoulhon

[tscrim]

comment:45

Sounds good to me. I will play around with the Real/Complex axioms and things to get something reasonable.

I will take objections and alternative ideas at any point forward too.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from e6076d2 to c89b7c6

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

c782e79	Merge branch 'public/categories/topological_metric_spaces-18175' into 6.9.b4
c89b7c6	trac #18175 fixing a typo in the doc

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

9a23df1	Merge branch 'public/categories/topological_metric_spaces-18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175
7c54c8a	Added axiom for Complete and made manifolds a category over a base ring.
3647305	Some cleanup and adding more category information to particular sets.
f810aa6	Reworking the category of manifolds.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from c89b7c6 to f810aa6

[tscrim]

comment:48

After much debate with myself, I ended up making the following:

   Manifolds
      | 
 Differentiable
      |
    Smooth
      |
   Analytic
  /        \
Almost     Complex

where Complex includes the holomorphic condition. I also added "complete" as an axiom and made some rings/fields into the finer categories they belong to (mainly ZZ, QQ, RR, CC into metric spaces, since they have a well-established distinguished natural metric); this allows the fields to work as the base of the manifold. If everyone can live with the current setup for now, then a quick check of my changes should yield a positive review (I hope).

[egourgoulhon]

comment:49

Thank you for this new setting of the manifold categories, very timely regarding #18528 ! A first quick remark: Almost should be under Smooth since analyticity is not requirred for an almost complex manifold; see e.g. https://en.wikipedia.org/wiki/Almost_complex_manifold.

[egourgoulhon]

comment:50

I gave a first look at the code; it looks good, but some doctests failed: running ./sage -t --long src/sage/categories/ with sage 6.10.beta0 results in sage -t --long src/sage/categories/map.pyx # 2 doctests failed sage -t --long src/sage/categories/category_types.py # 3 doctests failed sage -t --long src/sage/categories/primer.py # 2 doctests failed sage -t --long src/sage/categories/morphism.pyx # 1 doctest failed sage -t --long src/sage/categories/category.py # 11 doctests failed sage -t --long src/sage/categories/bimodules.py # 3 doctests failed sage -t --long src/sage/categories/homset.py # 3 doctests failed sage -t --long src/sage/categories/lie_groups.py # 5 doctests failed

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from f810aa6 to 375ff46

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

375ff46

Fixing doctest failures and letting a few other rings know they are metric spaces.

[tscrim]

comment:52

I made a mistake in my diagram. In the code, almost complex manifolds only imply smooth, not analytic.

I also noticed the test failures and have just pushed changes. Almost all were trivial doctest failures. I also made a few other variants of \RR and \CC know that they are also metric spaces.

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

[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!

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 375ff46 to f8f5b93

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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 ?

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

041a5d1

Adding p-adics to metric spaces and some cleanup.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

bfa0cdf

One last doc tweak.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 041a5d1 to bfa0cdf

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

d13c368

Fixing doc of metric spaces.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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

f6fdd7d

Some last little bit of cleanup.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

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.

[tscrim]

Description changed:

--- 
+++ 
@@ -9,8 +9,7 @@

 and axioms:

-- real
-- complex
+- complete
 - compact
 - analytic
 - differentiable

[vbraun]

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