Opened 2 years ago

Closed 18 months ago

#18175 closed enhancement (fixed)

Implement categories for topological and metric spaces and related categories

Reported by: tscrim Owned by: tscrim
Priority: major Milestone: sage-6.10
Component: categories Keywords: geometry, topology, sd67
Cc: nthiery, egourgoulhon Merged in:
Authors: Travis Scrimshaw Reviewers: Eric Gourgoulhon
Report Upstream: N/A Work issues:
Branch: f6fdd7d (Commits) Commit: f6fdd7ddad7fdbef37e7632d628f432891e76acc
Dependencies: #18174 #17160 Stopgaps:

Description (last modified by 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

Change History (66)

comment:1 follow-up: Changed 2 years ago by tscrim

  • Branch set to public/categories/topological_metric_spaces-18175
  • Commit set to 68b85e9898949b1d9707f5d62c467e7fa2467da9

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:

77b801cInital stubs
0e78e25Implement generic functorial construction base class magic.
96547d2Merge branch 'public/categories/functorial_magic-18174' into public/categories/topological_metric_spaces-TBA
bdb08fbSome cleanup and getting category stubs ready.
68b85e9Adding some more stubs for categories.

comment:2 Changed 2 years ago by tscrim

  • Dependencies set to #18174

comment:3 Changed 2 years ago by git

  • Commit changed from 68b85e9898949b1d9707f5d62c467e7fa2467da9 to aea3a7dea7fb5325b4e950be6c4c76b64c491cdd

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

cf9b429Fixed ReST typo
aff268917160: fixed category for finite set endomaps + minor __init__ refactoring
4b3d74cMerge branch 'develop' into categories/finitely-generated-magmas-17160
ad5d6c08678: permutation groups are finitely generated, finite fields are enumerated, fixes
839200e8678: More doctest updates. Should almost pass all tests.
919a215Merge branch 'develop = sage 6.6 beta6' into categories/finitely-generated-magmas-17160
ef01ef0Merge branch 't/18012/sphinx_depends_on_jinja2' into categories/finitely-generated-magmas-17160
975c008Merge branch 'u/nthiery/categories/finitely-generated-magmas-17160' of trac.sagemath.org:sage into categories/finitely-generated-magmas-17160
19ceb81Merge branch 'u/nthiery/categories/finitely-generated-magmas-17160' of trac.sagemath.org:sage into public/categories/finitely_generated_magma-17160
aea3a7dMerge branch 'public/categories/finitely_generated_magma-17160' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175

comment:4 Changed 2 years ago by tscrim

  • Dependencies changed from #18174 to #18174 #17160

Handled conflicts with #17160.

comment:5 in reply to: ↑ 1 Changed 2 years ago by egourgoulhon

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.

comment:6 Changed 2 years ago by nthiery

  • Keywords sd67 added

comment:7 follow-up: Changed 2 years ago by egourgoulhon

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.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 2 years ago by 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.

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

comment:9 in reply to: ↑ 8 ; follow-up: Changed 2 years ago by egourgoulhon

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.

comment:10 Changed 2 years ago by git

  • Commit changed from aea3a7dea7fb5325b4e950be6c4c76b64c491cdd to fcc3273fbb9e83da6c61027463e3ed4582009514

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

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

comment:11 in reply to: ↑ 9 ; follow-up: Changed 2 years ago by 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.

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

comment:12 in reply to: ↑ 11 Changed 2 years ago by egourgoulhon

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.

comment:13 Changed 2 years ago by git

  • Commit changed from fcc3273fbb9e83da6c61027463e3ed4582009514 to 5796cbd4fd66bdad4df405a4942f47e9d9d9c69a

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

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

comment:14 follow-up: Changed 2 years ago by tscrim

  • Milestone changed from sage-6.6 to sage-6.8

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.

comment:15 in reply to: ↑ 14 Changed 2 years ago by egourgoulhon

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

comment:16 Changed 2 years ago by jhpalmieri

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

comment:17 Changed 2 years ago by tscrim

I don't really hold a strong opinion on the definition of a manifold, so perhaps for the sake of clarity, we'll make this be local homeomorphic to kn, where k is a topological field.

However this brings up another point in the design for manifolds. When I first wrote this category, I was thinking all manifolds would be real and a subcategory for those who allow carry a complex structure. The reason for this is I was thinking of complex Lie groups, which can behave differently than their real/rational/positive-char counterparts. Yet I'm wondering if we should instead just parameterize the category and this gives a more consistent interface (and if we need a special complex subcategory, we still might want that parameterized by the complex field).

A more concrete (better) question is what do you want a complex manifold to be? Wikipedia says it is a manifold with holomorphic transition maps. Or should this be a smooth manifold over the complex numbers? In other words, should the notion of differentiability be inherent in the base field?

Thoughts?

comment:18 Changed 2 years ago by egourgoulhon

IMHO, a complex manifold should be a topological manifold over C (i.e. locally homeomorphic to Cn) with holomorphic transition maps. In the refactoring/split of SageManifolds I am preparing in #18528, I have relaxed the assumption of real manifolds used up to now and have introduced topological manifolds over a generic topological field, having in mind complex manifolds, in addition to real ones. In the implementation, each object of the class ComplexManifold could have an attribute which is an almost complex manifold. The latter would be a real smooth manifold of dimension 2n with an almost complex structure and would be implemented as a subclass of SmoothManifold. I have the impression that the category Manifolds that you are introducing in the current ticket is sufficient for this, i.e. it can be used for any topological manifold over a topological field. I plan to set the TopManifold objects of #18529 in this category. Then, the class ComplexManifold would inherit from TopManifold and would be set in the category Manifolds.Complex().

comment:19 Changed 2 years ago by git

  • Commit changed from 5796cbd4fd66bdad4df405a4942f47e9d9d9c69a to 95a30aa57fc62f23a884790b57835d107d8bdeef

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

95a30aaAdding examples of categories and full coverage.

comment:20 follow-up: Changed 2 years ago by tscrim

It still seems like we are having an assumption that all manifolds can inherently be realized over R. This was my initial assumption too, and so manifolds that could be locally homoemorphic to Cd were a special case.

However I feel like it would be best for Manifolds to be over an arbitrary topological field (which will require some very mild changes). So then the heirarchy for manifolds would be:

     Manifolds
        |
  Differentiable
        |
      Smooth
   /         \
Analytic    AlmostComplex
                |
             Complex

Do you think this what we want?

Also do we think we should add a stub category for PL and/or (pseudo) Riemannian manifolds? How about ManifoldsWithBoundary as a supercategory of Manifolds (and how many of these extra structures lift to the boundary)?

A question for CW complexes, should the elements of a CW complex be the cells or the points of the topological space? Right now, I'm taking the former approach, but I feel this might be an abuse as these should be subobjects of the category (Nicolas, any wisdom to impart on this?). If this seems like a non-trivial issue, I can split this ticket into 2 parts; one for the manifolds and one for the CW complexes.

Last edited 2 years ago by tscrim (previous) (diff)

comment:21 in reply to: ↑ 20 ; follow-up: Changed 2 years ago by egourgoulhon

Replying to tscrim:

However I feel like it would be best for Manifolds to be over an arbitrary topological field (which will require some very mild changes). So then the heirarchy for manifolds would be:

     Manifolds
        |
  Differentiable
        |
      Smooth
   /         \
Analytic    AlmostComplex
                |
             Complex

Do you think this what we want?

If manifolds are distinguished by their base field (after all, this is the base field that defines the dimension), an alternative hierarchy would be

            Manifolds
             /    \
        Complex  Differentiable
                       |
                     Smooth
                    /      \
                Analytic  AlmostComplex

with the understanding that

  • Manifolds: topological manifolds over a topological field K
  • Complex: topological manifolds over K=C with a holomorphic atlas
  • Differentiable: topological manifolds over K=R with a differentiable atlas
  • Smooth: topological manifolds over K=R with a Coo atlas
  • Analytic: topological manifolds over K=R with an analytic atlas
  • AlmostComplex: smooth manifolds with an almost complex structure

In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in comment:18, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.

Also do we think we should add a stub category for PL and/or (pseudo) Riemannian manifolds? How about ManifoldsWithBoundary as a supercategory of Manifolds (and how many of these extra structures lift to the boundary)?

Probably at some point, ManifoldsWithBoundary will be necessary, but this could be left for a second stage...

Last edited 2 years ago by egourgoulhon (previous) (diff)

comment:22 in reply to: ↑ 21 ; follow-up: Changed 2 years ago by tscrim

Replying to egourgoulhon:

  • Manifolds: topological manifolds over a topological field K
  • Complex: topological manifolds over K=C with a holomorphic atlas
  • Differentiable: topological manifolds over K=R with a differentiable atlas
  • Smooth: topological manifolds over K=R with a Coo atlas
  • Analytic: topological manifolds over K=R with an analytic atlas
  • AlmostComplex: smooth manifolds with an almost complex structure

However, I don't think we should impose the restriction for differentiable/smooth/analytic as being over R. See for instance http://www.iecn.u-nancy.fr/~bertram/simfin.pdf. Specifically, it would allow us to work over Q, where arithmetic is exact.

In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in comment:18, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.

This says that complex should be a subcategory of almost complex. However by parameterizing the manifolds category by the base field (like, e.g., Algebras), there will be no danger of ambiguity of considering an almost complex manifold as being over C or over R. This also means we could do the hierarchy I previously suggested (with a minor adjustment):

      Manifolds
          |
    Differentiable
          |
        Smooth
       /      \
  Analytic   AlmostComplex
       \      /
        Complex

In particular, this would allow us to consider a manifold over R that supports a complex structure (for instance, C considered as a 2-dim real manifold). Thus natural identifications could be given by functors.

comment:23 in reply to: ↑ 22 Changed 2 years ago by egourgoulhon

Replying to tscrim:

However, I don't think we should impose the restriction for differentiable/smooth/analytic as being over R. See for instance http://www.iecn.u-nancy.fr/~bertram/simfin.pdf.

If we can reach this level of generality, why not? I guess that when defining new categories for Sage, it's better to be as general as possible.

Specifically, it would allow us to work over Q, where arithmetic is exact.

In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in comment:18, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.

This says that complex should be a subcategory of almost complex. However by parameterizing the manifolds category by the base field (like, e.g., Algebras), there will be no danger of ambiguity of considering an almost complex manifold as being over C or over R. This also means we could do the hierarchy I previously suggested (with a minor adjustment):

      Manifolds
          |
    Differentiable
          |
        Smooth
       /      \
  Analytic   AlmostComplex
       \      /
        Complex

In particular, this would allow us to consider a manifold over R that supports a complex structure (for instance, C considered as a 2-dim real manifold). Thus natural identifications could be given by functors.

OK. I realize that my concern was more about the implementation of the Parent classes than about the categories: a priori, a complex manifold class cannot inherit from an almost complex class (despite of the name!) because it probably does not have any vanishing complex Nijenhuis tensor (although it has a vanishing real one), does it? BTW what is the opinion of John Palmieri about all this?

comment:24 Changed 2 years ago by bpillet

Hi,

I believe Almost Complex manifolds are real manifolds with added structure (namely a [1,1]-tensor), meanwhile complex manifolds can either be seen as

  • (a) Almost Complex manifold satisfying further axioms (integrability)
  • (b) Manifolds (over C) satisfying axioms (holomorphic transition)

The definitions (a) and (b) are equivalent, but the transition from (b) to (a) is easy meanwhile the transition (a) to (b) is given by the Newlander Nirenberg theorem and involves solving complicated PDEs which cannot be made automatic. Therefore, it should be implemented as different objects, because we cannot get complex coordinates from the knowledge of a vanishing Nijenhuis tensor.

Another consequence : Complex manifolds must have complex holomorphic coordinates hence it inherits from the analytic category. But should its coordinates seen as real analytic or complex analytic ?

  • It cannot be complex analytic since complex analytic manifolds are tautologically complex manifolds.
  • But, it should not be real analytic because from the same almost complex manifold with real analytic coordinates it may be impossible to get our complex manifold back. Moreover it makes no sense to consider complex coordinates which are real analytic (for example $\bar{z}$ as a coordinate on C) because it does not preserve the complex structure on C but only preserves the structure of R2.

I don't really know anything about manifolds over Q, but I fear transitions maps should also satisfy some rationality conditions, and more generally over any field, one have to take the good functions. Hence making the category looks like Algebra might be more difficult. Another example : over the "ring" of quaternions, what would be the good functions ? Actually, there are several definitions possible each yielding different theories.

Basile

comment:25 follow-up: Changed 23 months ago by tscrim

Hey Basile,

I'm not quite sure what you're proposing we should do for organizing the manifolds category. For the (a) <=> (b) condition, we aren't doing any sort of checking. By a user constructing a object (parent) in a category, the user is simply promising that it carries that structure.

We could make it so there is no parameterization of the categories (on the underlying field), but instead have the condition for objects to be in the category that their base field be R or C as appropriate. However I think this leads to ambiguity of dimension (e.g., for complex manifolds, do you want the real or complex dimension?) and what you want your charts to be.

I think for fields like Q, the metric gives a good notation of convergence, limits, and hence differential calculus. So, e.g., for smooth manifolds, the transition maps would still be smooth maps (just now in terms of Q calculus instead of R calculus).

Are you perhaps suggesting we should do something like the digram in comment:21?

comment:26 in reply to: ↑ 25 Changed 23 months ago by bpillet

Replying to tscrim:

Hey Basile,

Hi,

I'm not quite sure what you're proposing we should do for organizing the manifolds category. For the (a) <=> (b) condition, we aren't doing any sort of checking. By a user constructing a object (parent) in a category, the user is simply promising that it carries that structure.

We could make it so there is no parameterization of the categories (on the underlying field), but instead have the condition for objects to be in the category that their base field be R or C as appropriate. However I think this leads to ambiguity of dimension (e.g., for complex manifolds, do you want the real or complex dimension?) and what you want your charts to be.

I'm sorry I was not very clear. In my opinion it is important to distinguish manifolds over R and over C. AlmostComplex should be seen as manifolds over R enriched, but ComplexManifold should not inherit from AlmostComplex. At least so that dimension or charts would be unambiguous. (There would still exist a coercion from ComplexManifold to AlmostComplex but not coming from class heritage).

Are you perhaps suggesting we should do something like the digram in comment:21?

Yes actually. Because in the following diagram where everything is parametrised on the underlying field, the case F=C makes no sense. Indeed Differentiable/C cannot exist since usual differentiable maps are not C-linear. Or else if you define it to be C-differentiable then it is the same as Smooth/C and Analytic/C

   Manifolds/F
       |  
Differentiable/F
       |
    Smooth/F
       |
   Analytic/F

I'm not sure, where, in the implementation the issue may appear... For example, in the case of finite fields : x --> xp is not smooth on F_p but it is analytic, which contradicts the heritage.

Basile

comment:27 follow-up: Changed 23 months ago by tscrim

For the record, I'm not much of an expert in manifolds; most of my knowledge comes from reading wikipedia.

So you're saying there should be a canonical functor from complex manifolds to almost complex manifolds given by changing the base field from C to R (as opposed to it being a subcategory)? From what you said, this seems to be the best course of action.

For the example with finite fields, do they have a reasonable topology and could that define a transition map? If so, then I think we should enforce differentiable as being over R.

comment:28 in reply to: ↑ 27 ; follow-up: Changed 23 months ago by egourgoulhon

Replying to tscrim:

So you're saying there should be a canonical functor from complex manifolds to almost complex manifolds given by changing the base field from C to R (as opposed to it being a subcategory)? From what you said, this seems to be the best course of action.

This seems also the best to me.

For the example with finite fields, do they have a reasonable topology and could that define a transition map? If so, then I think we should enforce differentiable as being over R.

If we enforce this, then we are back to the diagram of comment:21. But I wonder now if a best strategy would be to leave instead the base field generic, with the understanding that differentiable means K-differentiable, where K stands for the base field. Then the diagram becomes

            Manifolds
               |
         Differentiable
               |
            Smooth
           /      \
      Analytic   AlmostComplex
         |
      Complex

with

  • Manifolds: topological manifolds over a topological field K
  • Differentiable: topological manifolds over K with a K-differentiable atlas
  • Smooth: topological manifolds over K with a K-infinitely differentiable atlas
  • Analytic: topological manifolds over K with a K-analytic atlas
  • AlmostComplex: smooth manifolds over K=R with an almost complex structure
  • Complex: C-analytic manifolds over K=C

comment:29 in reply to: ↑ 28 ; follow-up: Changed 23 months ago by bpillet

Hi Eric,

Replying to egourgoulhon:

[...] I wonder now if a best strategy would be to leave instead the base field generic, with the understanding that differentiable means K-differentiable, where K stands for the base field.

As I said, there are case for some fields K where K-analytic is weaker than expected : For example I can make a change of charts x --> xp over F_p which is actually invertible since xp is the identity on F_p but when computing its differential it vanishes identically since pxp-1 = 0 in caracteristic p.

In my opinion (which is strongly disputable as I don't have a very wide knowledge of the existing theories) differential geometry is meant for R and C (or maybe in extremal cases over p-adic fields) but over other field the right way of doing geometry is through algebraic geometry : Manifolds or varieties are no longer given by charts but by equations.

However, there is still hope of having K-manifolds : The essential piece of information on a scheme (the algebraic geometry object generalising manifolds) is the seaf of functions. But we do have, within Sage Manifolds, a similar object : The set of ScalarFields over an open domain. The rest is just algebra over that (sheaf of) ring. Yet I don't have any idea whether it is actually possible to implement algebraic geometry, and if there would be any use of such (gigantic) work.

Replying to tscrim:

So you're saying there should be a canonical functor from complex manifolds to almost complex manifolds given by changing the base field from C to R (as opposed to it being a subcategory)? From what you said, this seems to be the best course of action.

Yes and actually this is easy : Take a complex manifold with chart over U given by complex valued functions zk and let xk + i yk their decompositions into real and imaginary parts. Then (x1,y1, ... , xn,yn) is a chart over U of the underlying real manifold. On which we get an almost complex structure for free, given by J \partial_{xk} = \partial_{yk} (Structure recalling which coordinate x and y are to be glued together to make complex coordinates)

This can be seen at the level of the most elementary examples : The class Manifold has a single object subclass : RealLine (of dimension 1) which encodes the manifold R. For the complex there should be 2 cases :

  • ComplexLine (single object subclass of ComplexManifolds) of dimension 1 (over C) with canonical chart (C,z)
  • ComplexPlane(single object subclass of AlmostComplexManifolds) of dimension 2 (over R) with canonical chart (C,(x,y)) and complex structure given by J_0 \partial_x = \partial_y

The functor applied to ComplexLine would yield the ComplexPlane.

comment:30 in reply to: ↑ 29 Changed 23 months ago by egourgoulhon

Hi Basile,

Replying to bpillet:

As I said, there are case for some fields K where K-analytic is weaker than expected : For example I can make a change of charts x --> xp over F_p which is actually invertible since xp is the identity on F_p but when computing its differential it vanishes identically since pxp-1 = 0 in caracteristic p.

Thanks for this example!

In my opinion (which is strongly disputable as I don't have a very wide knowledge of the existing theories) differential geometry is meant for R and C (or maybe in extremal cases over p-adic fields) but over other field the right way of doing geometry is through algebraic geometry : Manifolds or varieties are no longer given by charts but by equations.

Yes, you are right, for differentiable manifolds, we should probably limit ourselves to K=C or K=R (at least in a first stage). In the refactoring of SageManifolds I am preparing for #18528, I leave the base field generic anyway. In the documentation of class TopManifold in #18529, you can see already an example with K=C (the Riemann sphere as a topological manifold of dimension 1 over C).

comment:31 Changed 23 months ago by egourgoulhon

  • Description modified (diff)

comment:32 Changed 22 months ago by git

  • Commit changed from 95a30aa57fc62f23a884790b57835d107d8bdeef to 29a97a7919ce9847c1957111f08114b8947d52ec

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

31ba0b5Merge branch 'public/categories/topological_metric_spaces-18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces-18175
da729ccAdded more axioms and reworked the manifolds category structure.
20a71aeMerge branch 'develop' into public/categories/topological_metric_spaces-18175
5418b0fMerge branch 'develop' into public/categories/topological_metric_spaces-18175
29a97a7Minor fixes and reorganizing the manifolds categories.

comment:33 follow-up: Changed 22 months ago by tscrim

  • Description modified (diff)
  • Status changed from new to needs_review

Given our discussion, I have reorganized the manifolds category as:

        Manifolds
         /    \
    Complex   Real
               |
          Differentiable
               |
             Smooth
            /      \
       Analytic  AlmostComplex

I've added full doctest coverage and some examples. So ready for proper review.

PS - Sorry it took so long to get back to this.

Last edited 22 months ago by tscrim (previous) (diff)

comment:34 Changed 22 months ago by git

  • Commit changed from 29a97a7919ce9847c1957111f08114b8947d52ec to e6076d2a41dbe5e3294c03a95e3e763e60d554ff

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

e6076d2Fixing failing doctests and last tweaks.

comment:35 Changed 22 months ago by tscrim

Nicolas, question for you. I'm not sure that the subcategories of Manifolds should be subclasses of CategoryWithAxiom. In particular, the Complex and Real and if they should be axioms. Would they still work with FiniteDimensional and Connected axioms?

comment:36 in reply to: ↑ 33 Changed 22 months ago by egourgoulhon

Hi Travis,

Replying to tscrim:

Given our discussion, I have reorganized the manifolds category as:

        Manifolds
         /    \
    Complex   Real
               |
          Differentiable
               |
             Smooth
            /      \
       Analytic  AlmostComplex

It seems to me that Real should not be atop Differentiable in this hierarchy. Indeed, there exist differentiable manifolds over fields other than R or C: for instance differentiable manifolds over the field of p-adic numbers, Q_p: see e.g. Part II of J.-P. Serre's book Lie Algebras and Lie Groups (1992), where differentiable (actually analytic) manifolds over Q_p are introduced. For this reason, in the refactoring of SageManifolds I am preparing in #18783, I have left the base field generic (notice that we do have the fields of p-adic numbers in Sage). So it would be nice to be able to set the category to Manifolds().Differentiable() without having to assume that the base field is R. Similarly, I think that Complex should be a subcategory of Analytic. As you suggest in comment:35, maybe Complex and Real should be axioms, rather than appearing in the above hierarchy...

I've added full doctest coverage and some examples. So ready for proper review.

PS - Sorry it took so long to get back to this.

Thank you for working on this!

comment:37 follow-up: Changed 22 months ago by tscrim

So then you'd do the diagram in comment:28, in contrast to your statement in comment:30? Or did you mean something different in comment:30? I can also make it so the hierarchy is dynamic, in that if k has characteristic p, then analytic does not imply smooth. The category hierarchy does not have to be static (for the record, these are not subclasses, but subcategories in the mathematical sense).

I don't really care what the final hierarchy looks like, but I want it to be as mathematically correct as possible and you (and Michal) and Basile agree. (Although I do have a bias towards making things as general as possible.)

As far as making them be axioms vs singleton categories, this is more of an implementation detail.

comment:38 in reply to: ↑ 37 Changed 22 months ago by egourgoulhon

Replying to tscrim:

So then you'd do the diagram in comment:28, in contrast to your statement in comment:30?

Yes this is more or less what I mean. Sorry for the confusion... Actually in preparing the code for differentiable manifolds in #18783, I realize that (i) we can allow very easily for a base field different from R or C and (ii) differentiable manifolds over fields different from R or C are not so uncommon in the literature, in particular manifolds over Q_p. Basically the topological field has to be a complete metric space (as Q_p is), so that the notion of differentiability makes sense.

comment:39 Changed 22 months ago by tscrim

So it seems like I should add an additional axiom "complete" and have it apply to metric spaces and then check that the field passed to Manifolds should be a complete metric space. On a followup ticket, we will change the category of those fields which are (models for) complete metric spaces, such as R variants like RealField.

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

comment:41 in reply to: ↑ 40 Changed 22 months ago by egourgoulhon

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.

comment:42 Changed 20 months ago by tscrim

ping

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

comment:43 Changed 20 months ago by egourgoulhon

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?

comment:44 Changed 20 months ago by egourgoulhon

  • Reviewers set to Eric Gourgoulhon

comment:45 Changed 20 months ago by tscrim

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.

comment:46 Changed 20 months ago by git

  • Commit changed from e6076d2a41dbe5e3294c03a95e3e763e60d554ff to c89b7c6ef04215e33ad810ab0a7936317233723a

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

c782e79Merge branch 'public/categories/topological_metric_spaces-18175' into 6.9.b4
c89b7c6trac #18175 fixing a typo in the doc

comment:47 Changed 19 months ago by git

  • Commit changed from c89b7c6ef04215e33ad810ab0a7936317233723a to f810aa668c8d0c74ec861e9ab307bedc7777036a

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

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

comment:48 Changed 19 months ago by tscrim

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

comment:49 Changed 19 months ago by egourgoulhon

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.

comment:50 Changed 19 months ago by egourgoulhon

  • Status changed from needs_review to needs_work

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

comment:51 Changed 19 months ago by git

  • Commit changed from f810aa668c8d0c74ec861e9ab307bedc7777036a to 375ff46221b7dcc101536774664b4bb935f99fba

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

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

comment:52 follow-up: Changed 19 months ago by tscrim

  • Milestone changed from sage-6.8 to sage-6.10
  • Status changed from needs_work to needs_review

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.

comment:53 Changed 19 months ago by egourgoulhon

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

comment:54 in reply to: ↑ 52 Changed 19 months ago by nthiery

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!

comment:55 Changed 19 months ago by git

  • Commit changed from 375ff46221b7dcc101536774664b4bb935f99fba to f8f5b93028708eebb745a1cc92f3b775a760108b

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

8b851a0Merge branch 'develop' into public/categories/topological_metric_spaces-18175
f8f5b93Fixing last remaining doctests.

comment:56 follow-up: Changed 19 months ago by egourgoulhon

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 ?

comment:57 Changed 19 months ago by git

  • Commit changed from f8f5b93028708eebb745a1cc92f3b775a760108b to 041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0

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

041a5d1Adding p-adics to metric spaces and some cleanup.

comment:58 in reply to: ↑ 56 ; follow-up: Changed 19 months ago by 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.

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

comment:59 Changed 19 months ago by git

  • Commit changed from 041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0 to bfa0cdf3696eadd6c2307f96dd366916746d5366

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

bfa0cdfOne last doc tweak.

comment:60 Changed 19 months ago by git

  • Commit changed from bfa0cdf3696eadd6c2307f96dd366916746d5366 to d13c3688328149c08f4efbbcee91a8fd2978d91a

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

d13c368Fixing doc of metric spaces.

comment:61 in reply to: ↑ 58 ; follow-up: Changed 18 months ago by egourgoulhon

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

comment:62 Changed 18 months ago by git

  • Commit changed from d13c3688328149c08f4efbbcee91a8fd2978d91a to f6fdd7ddad7fdbef37e7632d628f432891e76acc

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

f6fdd7dSome last little bit of cleanup.

comment:63 in reply to: ↑ 61 ; follow-up: Changed 18 months ago by tscrim

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

comment:64 in reply to: ↑ 63 Changed 18 months ago by egourgoulhon

  • Status changed from needs_review to positive_review

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.

comment:65 Changed 18 months ago by tscrim

  • Description modified (diff)

Thanks for doing the review.

comment:66 Changed 18 months ago by vbraun

  • Branch changed from public/categories/topological_metric_spaces-18175 to f6fdd7ddad7fdbef37e7632d628f432891e76acc
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.