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:  sage6.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 )
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 followup: ↓ 5 Changed 2 years ago by
 Branch set to public/categories/topological_metric_spaces18175
 Commit set to 68b85e9898949b1d9707f5d62c467e7fa2467da9
comment:2 Changed 2 years ago by
 Dependencies set to #18174
comment:3 Changed 2 years ago by
 Commit changed from 68b85e9898949b1d9707f5d62c467e7fa2467da9 to aea3a7dea7fb5325b4e950be6c4c76b64c491cdd
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/finitelygeneratedmagmas17160

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/finitelygeneratedmagmas17160

ef01ef0  Merge branch 't/18012/sphinx_depends_on_jinja2' into categories/finitelygeneratedmagmas17160

975c008  Merge branch 'u/nthiery/categories/finitelygeneratedmagmas17160' of trac.sagemath.org:sage into categories/finitelygeneratedmagmas17160

19ceb81  Merge branch 'u/nthiery/categories/finitelygeneratedmagmas17160' of trac.sagemath.org:sage into public/categories/finitely_generated_magma17160

aea3a7d  Merge branch 'public/categories/finitely_generated_magma17160' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175

comment:4 Changed 2 years ago by
 Dependencies changed from #18174 to #18174 #17160
Handled conflicts with #17160.
comment:5 in reply to: ↑ 1 Changed 2 years ago by
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
 Keywords sd67 added
comment:7 followup: ↓ 8 Changed 2 years ago by
Hi Travis,
I gave a look at the category Manifolds
; it looks nice and I have the following comments:
 the methods
dimension()
andFiniteDimensional()
, and well as the classFiniteDimensional
, are defined only at the level ofConnected
; shouldn't they be at the level ofManifolds
itself ?  in the docstring of
Manifolds
, I think the phrase "such that the neighborhood of any pointx \in M
is homeomorphic tok^d
" should be changed to something like "such that any pointx\in M
admits a neighborhood homeomorphic tok^d
"
Eric.
comment:8 in reply to: ↑ 7 ; followup: ↓ 9 Changed 2 years ago by
Replying to egourgoulhon:
 the methods
dimension()
andFiniteDimensional()
, and well as the classFiniteDimensional
, are defined only at the level ofConnected
; shouldn't they be at the level ofManifolds
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 1sphere and 2sphere 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 pointx \in M
is homeomorphic tok^d
" should be changed to something like "such that any pointx\in M
admits a neighborhood homeomorphic tok^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 ; followup: ↓ 11 Changed 2 years ago by
Replying to tscrim:
Replying to egourgoulhon:
 the methods
dimension()
andFiniteDimensional()
, and well as the classFiniteDimensional
, are defined only at the level ofConnected
; shouldn't they be at the level ofManifolds
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 1sphere and 2sphere 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 1sphere and a 2sphere 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 pointx \in M
is homeomorphic tok^d
" should be changed to something like "such that any pointx\in M
admits a neighborhood homeomorphic tok^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
 Commit changed from aea3a7dea7fb5325b4e950be6c4c76b64c491cdd to fcc3273fbb9e83da6c61027463e3ed4582009514
Branch pushed to git repo; I updated commit sha1. New commits:
349fe0f  Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175

fcc3273  Move dim to all manifolds, move methods from Hplane to metric spaces, some fixes.

comment:11 in reply to: ↑ 9 ; followup: ↓ 12 Changed 2 years ago by
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 1sphere and 2sphere 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 1sphere and a 2sphere 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 pointx \in M
is homeomorphic tok^d
" should be changed to something like "such that any pointx\in M
admits a neighborhood homeomorphic tok^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 lastminute 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
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 1sphere and 2sphere 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 1sphere and a 2sphere 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 nonstandard (*) 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
 Commit changed from fcc3273fbb9e83da6c61027463e3ed4582009514 to 5796cbd4fd66bdad4df405a4942f47e9d9d9c69a
Branch pushed to git repo; I updated commit sha1. New commits:
5796cbd  Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175

comment:14 followup: ↓ 15 Changed 2 years ago by
 Milestone changed from sage6.6 to sage6.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
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, welldefined dimension. This rules out, for example, spaces such as a disjoint union of a line and a plane in R^{3} ". 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
My professional opinion as a topologist is that a manifold should have a welldefined dimension n, and every point of that manifold should have a neighborhood homeomorphic to R^{n}. 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
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 k^{n}, 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/positivechar 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
IMHO, a complex manifold should be a topological manifold over C (i.e. locally homeomorphic to C^{n}) 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
 Commit changed from 5796cbd4fd66bdad4df405a4942f47e9d9d9c69a to 95a30aa57fc62f23a884790b57835d107d8bdeef
Branch pushed to git repo; I updated commit sha1. New commits:
95a30aa  Adding examples of categories and full coverage.

comment:20 followup: ↓ 21 Changed 2 years ago by
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 C^{d} 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 nontrivial issue, I can split this ticket into 2 parts; one for the manifolds and one for the CW complexes.
comment:21 in reply to: ↑ 20 ; followup: ↓ 22 Changed 2 years ago by
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  ComplexDo 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 KComplex
: topological manifolds over K=C with a holomorphic atlasDifferentiable
: topological manifolds over K=R with a differentiable atlasSmooth
: topological manifolds over K=R with a C^{oo} atlasAnalytic
: topological manifolds over K=R with an analytic atlasAlmostComplex
: 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 ofManifolds
(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...
comment:22 in reply to: ↑ 21 ; followup: ↓ 23 Changed 2 years ago by
Replying to egourgoulhon:
Manifolds
: topological manifolds over a topological field KComplex
: topological manifolds over K=C with a holomorphic atlasDifferentiable
: topological manifolds over K=R with a differentiable atlasSmooth
: topological manifolds over K=R with a C^{oo} atlasAnalytic
: topological manifolds over K=R with an analytic atlasAlmostComplex
: 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.unancy.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 2dim real manifold). Thus natural identifications could be given by functors.
comment:23 in reply to: ↑ 22 Changed 2 years ago by
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.unancy.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 \ / ComplexIn particular, this would allow us to consider a manifold over R that supports a complex structure (for instance, C considered as a 2dim 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
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 R^{2}^{. }
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 followup: ↓ 26 Changed 23 months ago by
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
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 Clinear. Or else if you define it to be Cdifferentiable 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 > x^{p} is not smooth on F_p but it is analytic, which contradicts the heritage.
Basile
comment:27 followup: ↓ 28 Changed 23 months ago by
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 ; followup: ↓ 29 Changed 23 months ago by
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 Kdifferentiable, 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 KDifferentiable
: topological manifolds over K with a Kdifferentiable atlasSmooth
: topological manifolds over K with a Kinfinitely differentiable atlasAnalytic
: topological manifolds over K with a Kanalytic atlasAlmostComplex
: smooth manifolds over K=R with an almost complex structureComplex
: Canalytic manifolds over K=C
comment:29 in reply to: ↑ 28 ; followup: ↓ 30 Changed 23 months ago by
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 Kdifferentiable, where K stands for the base field.
As I said, there are case for some fields K where Kanalytic is weaker than expected : For example I can make a change of charts x > x^{p} over F_p which is actually invertible since x^{p} is the identity on F_p but when computing its differential it vanishes identically since px^{p1} = 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 padic 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 Kmanifolds : 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 z^{k} and let x^{k} + i y^{k} their decompositions into real and imaginary parts. Then (x^{1},y^{1}, ... , x^{n},y^{n}) is a chart over U of the underlying real manifold. On which we get an almost complex structure for free, given by J \partial_{x^{k}} = \partial_{y^{k}} (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 ofComplexManifolds
) of dimension 1 (over C) with canonical chart (C,z)ComplexPlane
(single object subclass ofAlmostComplexManifolds
) 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
Hi Basile,
Replying to bpillet:
As I said, there are case for some fields K where Kanalytic is weaker than expected : For example I can make a change of charts x > x^{p} over F_p which is actually invertible since x^{p} is the identity on F_p but when computing its differential it vanishes identically since px^{p1} = 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 padic 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
 Description modified (diff)
comment:32 Changed 22 months ago by
 Commit changed from 95a30aa57fc62f23a884790b57835d107d8bdeef to 29a97a7919ce9847c1957111f08114b8947d52ec
Branch pushed to git repo; I updated commit sha1. New commits:
31ba0b5  Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175

da729cc  Added more axioms and reworked the manifolds category structure.

20a71ae  Merge branch 'develop' into public/categories/topological_metric_spaces18175

5418b0f  Merge branch 'develop' into public/categories/topological_metric_spaces18175

29a97a7  Minor fixes and reorganizing the manifolds categories.

comment:33 followup: ↓ 36 Changed 22 months ago by
 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.
comment:34 Changed 22 months ago by
 Commit changed from 29a97a7919ce9847c1957111f08114b8947d52ec to e6076d2a41dbe5e3294c03a95e3e763e60d554ff
Branch pushed to git repo; I updated commit sha1. New commits:
e6076d2  Fixing failing doctests and last tweaks.

comment:35 Changed 22 months ago by
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
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 padic 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 padic 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 followup: ↓ 38 Changed 22 months ago by
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
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
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 followup: ↓ 41 Changed 22 months ago by
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 nonsmooth. Let me know what you think is best.
comment:41 in reply to: ↑ 40 Changed 22 months ago by
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 nonsmooth. 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
ping
For the record, I'm okay with general topological fields.
comment:43 Changed 20 months ago by
Hi Travis, Sorry for the delay. If you agree with general topological fields (nondiscrete 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
 Reviewers set to Eric Gourgoulhon
comment:45 Changed 20 months ago by
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
 Commit changed from e6076d2a41dbe5e3294c03a95e3e763e60d554ff to c89b7c6ef04215e33ad810ab0a7936317233723a
comment:47 Changed 19 months ago by
 Commit changed from c89b7c6ef04215e33ad810ab0a7936317233723a to f810aa668c8d0c74ec861e9ab307bedc7777036a
Branch pushed to git repo; I updated commit sha1. New commits:
9a23df1  Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175

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.

comment:48 Changed 19 months ago by
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 wellestablished 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
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
 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
 Commit changed from f810aa668c8d0c74ec861e9ab307bedc7777036a to 375ff46221b7dcc101536774664b4bb935f99fba
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.

comment:52 followup: ↓ 54 Changed 19 months ago by
 Milestone changed from sage6.8 to sage6.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
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
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
 Commit changed from 375ff46221b7dcc101536774664b4bb935f99fba to f8f5b93028708eebb745a1cc92f3b775a760108b
comment:56 followup: ↓ 58 Changed 19 months ago by
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 padic 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
 Commit changed from f8f5b93028708eebb745a1cc92f3b775a760108b to 041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0
Branch pushed to git repo; I updated commit sha1. New commits:
041a5d1  Adding padics to metric spaces and some cleanup.

comment:58 in reply to: ↑ 56 ; followup: ↓ 61 Changed 19 months ago by
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 padic 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() FalseOne should actually have
sage: Qp(5) in Fields().Metric().Complete() TrueThere 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
 Commit changed from 041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0 to bfa0cdf3696eadd6c2307f96dd366916746d5366
Branch pushed to git repo; I updated commit sha1. New commits:
bfa0cdf  One last doc tweak.

comment:60 Changed 19 months ago by
 Commit changed from bfa0cdf3696eadd6c2307f96dd366916746d5366 to d13c3688328149c08f4efbbcee91a8fd2978d91a
Branch pushed to git repo; I updated commit sha1. New commits:
d13c368  Fixing doc of metric spaces.

comment:61 in reply to: ↑ 58 ; followup: ↓ 63 Changed 18 months ago by
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 theabs
method of the elements. I also made it so that there is a call loopP.metric > E.dist > P.dist > E.abs > P.metric
so one just needs to implement one of these methods (P
is the parent andE
is the element). This is a slight abuse as not all metric spaces have a0
(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 padic 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
 Commit changed from d13c3688328149c08f4efbbcee91a8fd2978d91a to f6fdd7ddad7fdbef37e7632d628f432891e76acc
Branch pushed to git repo; I updated commit sha1. New commits:
f6fdd7d  Some last little bit of cleanup.

comment:63 in reply to: ↑ 61 ; followup: ↓ 64 Changed 18 months ago by
Replying to egourgoulhon:
I've merged the last commit of this ticket in all the tickets of #18528, replacing the
Sets()
category byManifolds(K)
,Manifolds(K).Differentiable()
orManifolds(K).Smooth()
, withK
=RR
,Qp(5)
orCC
. 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
andsrc/sage/categories/examples/cw_complexes.py
), the parents implement the methodan_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
 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 implementan_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:66 Changed 18 months ago by
 Branch changed from public/categories/topological_metric_spaces18175 to f6fdd7ddad7fdbef37e7632d628f432891e76acc
 Resolution set to fixed
 Status changed from positive_review to closed
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 0cells), 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:
Inital stubs
Implement generic functorial construction base class magic.
Merge branch 'public/categories/functorial_magic18174' into public/categories/topological_metric_spacesTBA
Some cleanup and getting category stubs ready.
Adding some more stubs for categories.