Sage: Ticket #18175: Implement categories for topological and metric spaces and related categories
https://trac.sagemath.org/ticket/18175
<p>
After a discussion at Sage Days 64, we decided to implement a variety of categories pertaining to geometry and topology to lend assistance to <a class="extlink" href="http://sagemanifolds.obspm.fr"><span class="icon"></span>SageManifolds</a> (<a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a>) and to generalize idioms in the hyperbolic geometry (<a class="closed ticket" href="https://trac.sagemath.org/ticket/9439" title="enhancement: hyperbolic geometry (closed: fixed)">#9439</a>). This implements the following categories:
</p>
<ul><li>topological spaces
</li><li>metric spaces
</li><li>manifolds
</li><li>CW complexes
</li><li>simplicial complexes (which has been needed, see <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/10667" title="enhancement: Morphisms and Objects of Categories (needs_work)">#10667</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/6099" title="enhancement: morphisms of simplicial complexes and the associated chain complex ... (closed: fixed)">#6099</a>)
</li><li>Lie groups
</li></ul><p>
and axioms:
</p>
<ul><li>complete
</li><li>compact
</li><li>analytic
</li><li>differentiable
</li><li>smooth
</li><li>almost complex
</li></ul>enusSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/18175
Trac 1.1.6tscrimMon, 13 Apr 2015 00:00:12 GMTcommit, branch set
https://trac.sagemath.org/ticket/18175#comment:1
https://trac.sagemath.org/ticket/18175#comment:1
<ul>
<li><strong>commit</strong>
set to <em>68b85e9898949b1d9707f5d62c467e7fa2467da9</em>
</li>
<li><strong>branch</strong>
set to <em>public/categories/topological_metric_spaces18175</em>
</li>
</ul>
<p>
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 <code>Finite</code> 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.
</p>
<p>
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.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=77b801c6de17159081eea9a1c3fdc4952bf4288a"><span class="icon"></span>77b801c</a></td><td><code>Inital stubs</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=0e78e25fbd6bee9af1bf5606411f8146075b739f"><span class="icon"></span>0e78e25</a></td><td><code>Implement generic functorial construction base class magic.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=96547d24b9d0217d98eb476b1254451897be859a"><span class="icon"></span>96547d2</a></td><td><code>Merge branch 'public/categories/functorial_magic18174' into public/categories/topological_metric_spacesTBA</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=bdb08fb0e246e3d9937ca67762dde3baa4d43725"><span class="icon"></span>bdb08fb</a></td><td><code>Some cleanup and getting category stubs ready.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=68b85e9898949b1d9707f5d62c467e7fa2467da9"><span class="icon"></span>68b85e9</a></td><td><code>Adding some more stubs for categories.</code>
</td></tr></table>
TickettscrimMon, 13 Apr 2015 00:00:30 GMTdependencies set
https://trac.sagemath.org/ticket/18175#comment:2
https://trac.sagemath.org/ticket/18175#comment:2
<ul>
<li><strong>dependencies</strong>
set to <em>#18174</em>
</li>
</ul>
TicketgitMon, 13 Apr 2015 00:06:41 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:3
https://trac.sagemath.org/ticket/18175#comment:3
<ul>
<li><strong>commit</strong>
changed from <em>68b85e9898949b1d9707f5d62c467e7fa2467da9</em> to <em>aea3a7dea7fb5325b4e950be6c4c76b64c491cdd</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=cf9b429455e3330ff76d544bf39bc9ff7c76e514"><span class="icon"></span>cf9b429</a></td><td><code>Fixed ReST typo</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=aff2689ac6a7f6b80c1d4678ff348761f6a38919"><span class="icon"></span>aff2689</a></td><td><code>17160: fixed category for finite set endomaps + minor __init__ refactoring</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=4b3d74c41cfec35c35ab2262d6dc17dd90ef3472"><span class="icon"></span>4b3d74c</a></td><td><code>Merge branch 'develop' into categories/finitelygeneratedmagmas17160</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=ad5d6c0dc9cf55eed4900ed76df26f4a3e86f73f"><span class="icon"></span>ad5d6c0</a></td><td><code>8678: permutation groups are finitely generated, finite fields are enumerated, fixes</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=839200e376b595f7bfe3247c55fc31adf0693ef3"><span class="icon"></span>839200e</a></td><td><code>8678: More doctest updates. Should almost pass all tests.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=919a215d94e8e14eb75818021fa3af38831daf5e"><span class="icon"></span>919a215</a></td><td><code>Merge branch 'develop = sage 6.6 beta6' into categories/finitelygeneratedmagmas17160</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=ef01ef0288027084170f033b8cb8b46fa2d47be6"><span class="icon"></span>ef01ef0</a></td><td><code>Merge branch 't/18012/sphinx_depends_on_jinja2' into categories/finitelygeneratedmagmas17160</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=975c008ade2bc70319c286d9eb09eacdc75cafed"><span class="icon"></span>975c008</a></td><td><code>Merge branch 'u/nthiery/categories/finitelygeneratedmagmas17160' of trac.sagemath.org:sage into categories/finitelygeneratedmagmas17160</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=19ceb8124d27ba0124fb08a232c05924bb7114b0"><span class="icon"></span>19ceb81</a></td><td><code>Merge branch 'u/nthiery/categories/finitelygeneratedmagmas17160' of trac.sagemath.org:sage into public/categories/finitely_generated_magma17160</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=aea3a7dea7fb5325b4e950be6c4c76b64c491cdd"><span class="icon"></span>aea3a7d</a></td><td><code>Merge branch 'public/categories/finitely_generated_magma17160' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175</code>
</td></tr></table>
TickettscrimMon, 13 Apr 2015 00:07:07 GMTdependencies changed
https://trac.sagemath.org/ticket/18175#comment:4
https://trac.sagemath.org/ticket/18175#comment:4
<ul>
<li><strong>dependencies</strong>
changed from <em>#18174</em> to <em>#18174 #17160</em>
</li>
</ul>
<p>
Handled conflicts with <a class="closed ticket" href="https://trac.sagemath.org/ticket/17160" title="enhancement: Finitely generated axiom for (mutiplicative) magmas, semigroups, ... (closed: fixed)">#17160</a>.
</p>
TicketegourgoulhonMon, 13 Apr 2015 08:38:16 GMT
https://trac.sagemath.org/ticket/18175#comment:5
https://trac.sagemath.org/ticket/18175#comment:5
<p>
Hi Travis,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:1" title="Comment 1">tscrim</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
<p>
Eric.
</p>
TicketnthieryMon, 13 Apr 2015 16:33:42 GMTkeywords changed
https://trac.sagemath.org/ticket/18175#comment:6
https://trac.sagemath.org/ticket/18175#comment:6
<ul>
<li><strong>keywords</strong>
<em>sd67</em> added
</li>
</ul>
TicketegourgoulhonWed, 15 Apr 2015 09:15:07 GMT
https://trac.sagemath.org/ticket/18175#comment:7
https://trac.sagemath.org/ticket/18175#comment:7
<p>
Hi Travis,
</p>
<p>
I gave a look at the category <code>Manifolds</code>; it looks nice and I have the following comments:
</p>
<ul><li>the methods <code>dimension()</code> and <code>FiniteDimensional()</code>, and well as the class <code>FiniteDimensional</code>, are defined only at the level of <code>Connected</code>; shouldn't they be at the level of <code>Manifolds</code> itself ?
</li><li>in the docstring of <code>Manifolds</code>, I think the phrase "such that the neighborhood of any point <code>x \in M</code> is homeomorphic to <code>k^d</code>" should be changed to something like "such that any point <code>x\in M</code> admits a neighborhood homeomorphic to <code>k^d</code>"
</li></ul><p>
Eric.
</p>
TickettscrimMon, 20 Apr 2015 07:02:29 GMT
https://trac.sagemath.org/ticket/18175#comment:8
https://trac.sagemath.org/ticket/18175#comment:8
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:7" title="Comment 7">egourgoulhon</a>:
</p>
<blockquote class="citation">
<ul><li>the methods <code>dimension()</code> and <code>FiniteDimensional()</code>, and well as the class <code>FiniteDimensional</code>, are defined only at the level of <code>Connected</code>; shouldn't they be at the level of <code>Manifolds</code> itself ?
</li></ul></blockquote>
<p>
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.
</p>
<blockquote class="citation">
<ul><li>in the docstring of <code>Manifolds</code>, I think the phrase "such that the neighborhood of any point <code>x \in M</code> is homeomorphic to <code>k^d</code>" should be changed to something like "such that any point <code>x\in M</code> admits a neighborhood homeomorphic to <code>k^d</code>"
</li></ul></blockquote>
<p>
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.
</p>
TicketegourgoulhonMon, 20 Apr 2015 11:27:44 GMT
https://trac.sagemath.org/ticket/18175#comment:9
https://trac.sagemath.org/ticket/18175#comment:9
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:8" title="Comment 8">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:7" title="Comment 7">egourgoulhon</a>:
</p>
<blockquote class="citation">
<ul><li>the methods <code>dimension()</code> and <code>FiniteDimensional()</code>, and well as the class <code>FiniteDimensional</code>, are defined only at the level of <code>Connected</code>; shouldn't they be at the level of <code>Manifolds</code> itself ?
</li></ul></blockquote>
<p>
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.
</p>
</blockquote>
<p>
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 <code>Manifolds</code>.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>in the docstring of <code>Manifolds</code>, I think the phrase "such that the neighborhood of any point <code>x \in M</code> is homeomorphic to <code>k^d</code>" should be changed to something like "such that any point <code>x\in M</code> admits a neighborhood homeomorphic to <code>k^d</code>"
</li></ul></blockquote>
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
TicketgitSun, 10 May 2015 01:18:39 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:10
https://trac.sagemath.org/ticket/18175#comment:10
<ul>
<li><strong>commit</strong>
changed from <em>aea3a7dea7fb5325b4e950be6c4c76b64c491cdd</em> to <em>fcc3273fbb9e83da6c61027463e3ed4582009514</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=349fe0fc25622a4121690a4b1cab9f98e5a75ade"><span class="icon"></span>349fe0f</a></td><td><code>Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=fcc3273fbb9e83da6c61027463e3ed4582009514"><span class="icon"></span>fcc3273</a></td><td><code>Move dim to all manifolds, move methods from Hplane to metric spaces, some fixes.</code>
</td></tr></table>
TickettscrimSun, 10 May 2015 01:23:39 GMT
https://trac.sagemath.org/ticket/18175#comment:11
https://trac.sagemath.org/ticket/18175#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:9" title="Comment 9">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:8" title="Comment 8">tscrim</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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 <code>Manifolds</code>.
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<ul><li>in the docstring of <code>Manifolds</code>, I think the phrase "such that the neighborhood of any point <code>x \in M</code> is homeomorphic to <code>k^d</code>" should be changed to something like "such that any point <code>x\in M</code> admits a neighborhood homeomorphic to <code>k^d</code>"
</li></ul></blockquote>
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
TicketegourgoulhonTue, 19 May 2015 19:40:31 GMT
https://trac.sagemath.org/ticket/18175#comment:12
https://trac.sagemath.org/ticket/18175#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:11" title="Comment 11">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:9" title="Comment 9">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:8" title="Comment 8">tscrim</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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 <code>Manifolds</code>.
</p>
</blockquote>
<p>
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.
</p>
</blockquote>
<p>
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.
</p>
TicketgitFri, 29 May 2015 14:04:39 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:13
https://trac.sagemath.org/ticket/18175#comment:13
<ul>
<li><strong>commit</strong>
changed from <em>fcc3273fbb9e83da6c61027463e3ed4582009514</em> to <em>5796cbd4fd66bdad4df405a4942f47e9d9d9c69a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=5796cbd4fd66bdad4df405a4942f47e9d9d9c69a"><span class="icon"></span>5796cbd</a></td><td><code>Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175</code>
</td></tr></table>
TickettscrimFri, 29 May 2015 14:19:09 GMTmilestone changed
https://trac.sagemath.org/ticket/18175#comment:14
https://trac.sagemath.org/ticket/18175#comment:14
<ul>
<li><strong>milestone</strong>
changed from <em>sage6.6</em> to <em>sage6.8</em>
</li>
</ul>
<p>
On Wikipedia (<a class="extlink" href="http://en.wikipedia.org/wiki/Dimension"><span class="icon"></span>http://en.wikipedia.org/wiki/Dimension</a>), 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.
</p>
TicketegourgoulhonFri, 29 May 2015 21:24:53 GMT
https://trac.sagemath.org/ticket/18175#comment:15
https://trac.sagemath.org/ticket/18175#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:14" title="Comment 14">tscrim</a>:
</p>
<blockquote class="citation">
<p>
On Wikipedia (<a class="extlink" href="http://en.wikipedia.org/wiki/Dimension"><span class="icon"></span>http://en.wikipedia.org/wiki/Dimension</a>), they are careful to say a connected manifold.
</p>
</blockquote>
<p>
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 <em>pure manifold</em> 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: <em>"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<sup>3</sup> ".</em>
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.
</p>
TicketjhpalmieriFri, 29 May 2015 23:30:53 GMT
https://trac.sagemath.org/ticket/18175#comment:16
https://trac.sagemath.org/ticket/18175#comment:16
<p>
My professional opinion as a topologist is that a manifold should have a welldefined dimension <em>n</em>, and every point of that manifold should have a neighborhood homeomorphic to <strong>R</strong><sup><em>n</em></sup>. So even if it's not connected, the different components should have the same dimension.
</p>
<p>
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.)
</p>
TickettscrimSat, 30 May 2015 06:49:19 GMT
https://trac.sagemath.org/ticket/18175#comment:17
https://trac.sagemath.org/ticket/18175#comment:17
<p>
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 <strong>k</strong><sup>n</sup>, where <strong>k</strong> is a topological field.
</p>
<p>
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).
</p>
<p>
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?
</p>
<p>
Thoughts?
</p>
TicketegourgoulhonSat, 30 May 2015 07:30:49 GMT
https://trac.sagemath.org/ticket/18175#comment:18
https://trac.sagemath.org/ticket/18175#comment:18
<p>
IMHO, a complex manifold should be a topological manifold over <strong>C</strong> (i.e. locally homeomorphic to <strong>C</strong><sup>n</sup>) with holomorphic transition maps. In the refactoring/split of SageManifolds I am preparing in <a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a>, 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 <code>ComplexManifold</code> 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 <code>SmoothManifold</code>.
I have the impression that the category <code>Manifolds</code> 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 <code>TopManifold</code> objects of <a class="closed ticket" href="https://trac.sagemath.org/ticket/18529" title="enhancement: Topological manifolds: basics (closed: fixed)">#18529</a> in this category. Then, the class <code>ComplexManifold</code> would inherit from <code>TopManifold</code> and would be set in the category <code>Manifolds.Complex()</code>.
</p>
TicketgitSun, 31 May 2015 05:39:24 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:19
https://trac.sagemath.org/ticket/18175#comment:19
<ul>
<li><strong>commit</strong>
changed from <em>5796cbd4fd66bdad4df405a4942f47e9d9d9c69a</em> to <em>95a30aa57fc62f23a884790b57835d107d8bdeef</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=95a30aa57fc62f23a884790b57835d107d8bdeef"><span class="icon"></span>95a30aa</a></td><td><code>Adding examples of categories and full coverage.</code>
</td></tr></table>
TickettscrimSun, 31 May 2015 06:14:09 GMT
https://trac.sagemath.org/ticket/18175#comment:20
https://trac.sagemath.org/ticket/18175#comment:20
<p>
It still seems like we are having an assumption that all manifolds can inherently be realized over <strong>R</strong>. This was my initial assumption too, and so manifolds that could be locally homoemorphic to <strong>C</strong><sup>d</sup> were a special case.
</p>
<p>
However I feel like it would be best for <code>Manifolds</code> to be over an arbitrary topological field (which will require some very mild changes). So then the heirarchy for manifolds would be:
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth
/ \
Analytic AlmostComplex

Complex
</pre><p>
Do you think this what we want?
</p>
<p>
Also do we think we should add a stub category for PL and/or (pseudo) Riemannian manifolds? How about <code>ManifoldsWithBoundary</code> as a supercategory of <code>Manifolds</code> (and how many of these extra structures lift to the boundary)?
</p>
<p>
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.
</p>
TicketegourgoulhonSun, 31 May 2015 10:36:04 GMT
https://trac.sagemath.org/ticket/18175#comment:21
https://trac.sagemath.org/ticket/18175#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:20" title="Comment 20">tscrim</a>:
</p>
<blockquote class="citation">
<p>
However I feel like it would be best for <code>Manifolds</code> to be over an arbitrary topological field (which will require some very mild changes). So then the heirarchy for manifolds would be:
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth
/ \
Analytic AlmostComplex

Complex
</pre><p>
Do you think this what we want?
</p>
</blockquote>
<p>
If manifolds are distinguished by their base field (after all, this is the base field that defines the dimension), an alternative hierarchy would be
</p>
<pre class="wiki"> Manifolds
/ \
Complex Differentiable

Smooth
/ \
Analytic AlmostComplex
</pre><p>
with the understanding that
</p>
<ul><li><code>Manifolds</code>: topological manifolds over a topological field K
</li><li><code>Complex</code>: topological manifolds over K=<strong>C</strong> with a holomorphic atlas
</li><li><code>Differentiable</code>: topological manifolds over K=<strong>R</strong> with a differentiable atlas
</li><li><code>Smooth</code>: topological manifolds over K=<strong>R</strong> with a C<sup>oo</sup> atlas
</li><li><code>Analytic</code>: topological manifolds over K=<strong>R</strong> with an analytic atlas
</li><li><code>AlmostComplex</code>: smooth manifolds with an almost complex structure
</li></ul><p>
In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:18" title="Comment 18">comment:18</a>, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.
</p>
<blockquote class="citation">
<p>
Also do we think we should add a stub category for PL and/or (pseudo) Riemannian manifolds? How about <code>ManifoldsWithBoundary</code> as a supercategory of <code>Manifolds</code> (and how many of these extra structures lift to the boundary)?
</p>
</blockquote>
<p>
Probably at some point, <code>ManifoldsWithBoundary</code> will be necessary, but this could be left for a second stage...
</p>
TickettscrimSun, 31 May 2015 18:39:09 GMT
https://trac.sagemath.org/ticket/18175#comment:22
https://trac.sagemath.org/ticket/18175#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:21" title="Comment 21">egourgoulhon</a>:
</p>
<blockquote class="citation">
<ul><li><code>Manifolds</code>: topological manifolds over a topological field K
</li><li><code>Complex</code>: topological manifolds over K=<strong>C</strong> with a holomorphic atlas
</li><li><code>Differentiable</code>: topological manifolds over K=<strong>R</strong> with a differentiable atlas
</li><li><code>Smooth</code>: topological manifolds over K=<strong>R</strong> with a C<sup>oo</sup> atlas
</li><li><code>Analytic</code>: topological manifolds over K=<strong>R</strong> with an analytic atlas
</li><li><code>AlmostComplex</code>: smooth manifolds with an almost complex structure
</li></ul></blockquote>
<p>
However, I don't think we should impose the restriction for differentiable/smooth/analytic as being over <strong>R</strong>. See for instance <a class="extlink" href="http://www.iecn.unancy.fr/~bertram/simfin.pdf"><span class="icon"></span>http://www.iecn.unancy.fr/~bertram/simfin.pdf</a>. Specifically, it would allow us to work over <strong>Q</strong>, where arithmetic is exact.
</p>
<blockquote class="citation">
<p>
In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:18" title="Comment 18">comment:18</a>, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.
</p>
</blockquote>
<p>
This says that complex should be a subcategory of almost complex. However by parameterizing the manifolds category by the base field (like, e.g., <code>Algebras</code>), there will be no danger of ambiguity of considering an almost complex manifold as being over <strong>C</strong> or over <strong>R</strong>. This also means we could do the hierarchy I previously suggested (with a minor adjustment):
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth
/ \
Analytic AlmostComplex
\ /
Complex
</pre><p>
In particular, this would allow us to consider a manifold over <strong>R</strong> that supports a complex structure (for instance, <strong>C</strong> considered as a 2dim real manifold). Thus natural identifications could be given by functors.
</p>
TicketegourgoulhonMon, 01 Jun 2015 06:47:44 GMT
https://trac.sagemath.org/ticket/18175#comment:23
https://trac.sagemath.org/ticket/18175#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:22" title="Comment 22">tscrim</a>:
</p>
<blockquote class="citation">
<p>
However, I don't think we should impose the restriction for differentiable/smooth/analytic as being over <strong>R</strong>. See for instance <a class="extlink" href="http://www.iecn.unancy.fr/~bertram/simfin.pdf"><span class="icon"></span>http://www.iecn.unancy.fr/~bertram/simfin.pdf</a>.
</p>
</blockquote>
<p>
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.
</p>
<blockquote class="citation">
<p>
Specifically, it would allow us to work over <strong>Q</strong>, where arithmetic is exact.
</p>
<blockquote class="citation">
<p>
In particular, it seems to me that in the literature, "differentiable manifold" and "smooth manifold" always mean a real manifold. As mentionned in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:18" title="Comment 18">comment:18</a>, in the implementation a complex manifold of dimension n would be canonically associated to an almost complex manifold of dimension 2n.
</p>
</blockquote>
<p>
This says that complex should be a subcategory of almost complex. However by parameterizing the manifolds category by the base field (like, e.g., <code>Algebras</code>), there will be no danger of ambiguity of considering an almost complex manifold as being over <strong>C</strong> or over <strong>R</strong>. This also means we could do the hierarchy I previously suggested (with a minor adjustment):
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth
/ \
Analytic AlmostComplex
\ /
Complex
</pre><p>
In particular, this would allow us to consider a manifold over <strong>R</strong> that supports a complex structure (for instance, <strong>C</strong> considered as a 2dim real manifold). Thus natural identifications could be given by functors.
</p>
</blockquote>
<p>
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 <em>complex</em> Nijenhuis tensor (although it has a vanishing <em>real</em> one), does it?
BTW what is the opinion of John Palmieri about all this?
</p>
TicketbpilletMon, 01 Jun 2015 09:37:15 GMT
https://trac.sagemath.org/ticket/18175#comment:24
https://trac.sagemath.org/ticket/18175#comment:24
<p>
Hi,
</p>
<p>
I believe Almost Complex manifolds are real manifolds with <em>added structure</em> (namely a [1,1]tensor), meanwhile complex manifolds can either be seen as
</p>
<ul><li>(a) Almost Complex manifold <em>satisfying further axioms</em> (integrability)
</li><li>(b) Manifolds (over <strong>C</strong>) <em>satisfying axioms</em> (holomorphic transition)
</li></ul><p>
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.
</p>
<p>
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 ?
</p>
<ul><li>It cannot be complex analytic since complex analytic manifolds are tautologically complex manifolds.
</li><li>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 <strong>C</strong>) because it does not preserve the complex structure on <strong>C</strong> but only preserves the structure of <strong>R<sup>2</sup></strong><sup>.
</sup></li></ul><p>
I don't really know anything about manifolds over <strong>Q</strong>, but I fear transitions maps should also satisfy some <em>rationality conditions</em>, and more generally over any field, one have to take the good functions. Hence making the category looks like <code>Algebra</code> 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.
</p>
<p>
Basile
</p>
TickettscrimWed, 03 Jun 2015 21:59:26 GMT
https://trac.sagemath.org/ticket/18175#comment:25
https://trac.sagemath.org/ticket/18175#comment:25
<p>
Hey Basile,
</p>
<p>
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.
</p>
<p>
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 <strong>R</strong> or <strong>C</strong> 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.
</p>
<p>
I think for fields like <strong>Q</strong>, 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 <strong>Q</strong> calculus instead of <strong>R</strong> calculus).
</p>
<p>
Are you perhaps suggesting we should do something like the digram in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:21" title="Comment 21">comment:21</a>?
</p>
TicketbpilletThu, 04 Jun 2015 14:44:28 GMT
https://trac.sagemath.org/ticket/18175#comment:26
https://trac.sagemath.org/ticket/18175#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:25" title="Comment 25">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Hey Basile,
</p>
</blockquote>
<p>
Hi,
</p>
<blockquote class="citation">
<p>
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.
</p>
<p>
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 <strong>R</strong> or <strong>C</strong> 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.
</p>
</blockquote>
<p>
I'm sorry I was not very clear. In my opinion it is important to distinguish manifolds over <strong>R</strong> and over <strong>C</strong>. <code>AlmostComplex</code> should be seen as manifolds over <strong>R</strong> enriched, but <code>ComplexManifold</code> should not inherit from <code>AlmostComplex</code>. At least so that dimension or charts would be unambiguous.
(There would still exist a coercion from <code>ComplexManifold</code> to <code>AlmostComplex</code> but not coming from class heritage).
</p>
<blockquote class="citation">
<p>
Are you perhaps suggesting we should do something like the digram in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:21" title="Comment 21">comment:21</a>?
</p>
</blockquote>
<p>
Yes actually. Because in the following diagram where everything is parametrised on the underlying field, the case <strong>F</strong>=<strong>C</strong> makes no sense. Indeed <code>Differentiable/C</code> cannot exist since usual differentiable maps are not <strong>C</strong>linear. Or else if you define it to be <strong>C</strong>differentiable then it is the same as <code>Smooth/C</code> and <code>Analytic/C</code>
</p>
<pre class="wiki"> Manifolds/F

Differentiable/F

Smooth/F

Analytic/F
</pre><p>
I'm not sure, where, in the implementation the issue may appear...
For example, in the case of finite fields : x > x<sup>p</sup> is not smooth on F_p but it is analytic, which contradicts the heritage.
</p>
<p>
Basile
</p>
TickettscrimThu, 04 Jun 2015 19:13:01 GMT
https://trac.sagemath.org/ticket/18175#comment:27
https://trac.sagemath.org/ticket/18175#comment:27
<p>
For the record, I'm not much of an expert in manifolds; most of my knowledge comes from reading wikipedia.
</p>
<p>
So you're saying there should be a canonical functor from complex manifolds to almost complex manifolds given by changing the base field from <strong>C</strong> to <strong>R</strong> (as opposed to it being a subcategory)? From what you said, this seems to be the best course of action.
</p>
<p>
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 <strong>R</strong>.
</p>
TicketegourgoulhonFri, 05 Jun 2015 09:40:47 GMT
https://trac.sagemath.org/ticket/18175#comment:28
https://trac.sagemath.org/ticket/18175#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:27" title="Comment 27">tscrim</a>:
</p>
<blockquote class="citation">
<p>
So you're saying there should be a canonical functor from complex manifolds to almost complex manifolds given by changing the base field from <strong>C</strong> to <strong>R</strong> (as opposed to it being a subcategory)? From what you said, this seems to be the best course of action.
</p>
</blockquote>
<p>
This seems also the best to me.
</p>
<blockquote class="citation">
<p>
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 <strong>R</strong>.
</p>
</blockquote>
<p>
If we enforce this, then we are back to the diagram of <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:21" title="Comment 21">comment:21</a>. But I wonder now if a best strategy would be to leave instead the base field generic, with the understanding that <em>differentiable</em> means <strong>K</strong><em>differentiable</em>, where <strong>K</strong> stands for the base field. Then the diagram becomes
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth
/ \
Analytic AlmostComplex

Complex
</pre><p>
with
</p>
<ul><li><code>Manifolds</code>: topological manifolds over a topological field <strong>K</strong>
</li><li><code>Differentiable</code>: topological manifolds over <strong>K</strong> with a <strong>K</strong>differentiable atlas
</li><li><code>Smooth</code>: topological manifolds over <strong>K</strong> with a <strong>K</strong>infinitely differentiable atlas
</li><li><code>Analytic</code>: topological manifolds over <strong>K</strong> with a <strong>K</strong>analytic atlas
</li><li><code>AlmostComplex</code>: smooth manifolds over <strong>K</strong>=<strong>R</strong> with an almost complex structure
</li><li><code>Complex</code>: <strong>C</strong>analytic manifolds over <strong>K</strong>=<strong>C</strong>
</li></ul>
TicketbpilletFri, 05 Jun 2015 12:21:47 GMT
https://trac.sagemath.org/ticket/18175#comment:29
https://trac.sagemath.org/ticket/18175#comment:29
<p>
Hi Eric,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:28" title="Comment 28">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
[...] I wonder now if a best strategy would be to leave instead the base field generic, with the understanding that <em>differentiable</em> means <strong>K</strong><em>differentiable</em>, where <strong>K</strong> stands for the base field.
</p>
</blockquote>
<p>
As I said, there are case for some fields <strong>K</strong> where <strong>K</strong>analytic is weaker than expected : For example I can make a change of charts x > x<sup>p</sup> over F_p which is actually invertible since x<sup>p</sup> is the identity on F_p but when computing its differential it vanishes identically since px<sup>p1</sup> = 0 in caracteristic p.
</p>
<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 <strong>R</strong> and <strong>C</strong> (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.
</p>
<p>
However, there is still hope of having <strong>K</strong>manifolds : The essential piece of information on a scheme (the algebraic geometry object generalising manifolds) is the <em>seaf of functions</em>. But we do have, within Sage Manifolds, a similar object : The set of <code>ScalarFields</code> 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.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:27" title="Comment 27">tscrim</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
Yes and actually this is easy :
Take a complex manifold with chart over U given by complex valued functions z<sup>k</sup> and let x<sup>k</sup> + i y<sup>k</sup> their decompositions into real and imaginary parts. Then (x<sup>1</sup>,y<sup>1</sup>, ... , x<sup>n</sup>,y<sup>n</sup>) 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<sup>k</sup>} = \partial_{y<sup>k</sup>}
(Structure recalling which coordinate x and y are to be glued together to make complex coordinates)
</p>
<p>
This can be seen at the level of the most elementary examples :
The class <code>Manifold</code> has a single object subclass : <code>RealLine</code> (of dimension 1) which encodes the manifold <strong>R</strong>.
For the complex there should be 2 cases :
</p>
<ul><li><code>ComplexLine</code> (single object subclass of <code>ComplexManifolds</code>) of dimension 1 (over <strong>C</strong>) with canonical chart (<strong>C</strong>,z)
</li><li><code>ComplexPlane</code>(single object subclass of <code>AlmostComplexManifolds</code>) of dimension 2 (over <strong>R</strong>) with canonical chart (<strong>C</strong>,(x,y)) and complex structure given by J_0 \partial_x = \partial_y
</li></ul><p>
The functor applied to <code>ComplexLine</code> would yield the <code>ComplexPlane</code>.
</p>
TicketegourgoulhonFri, 05 Jun 2015 13:18:42 GMT
https://trac.sagemath.org/ticket/18175#comment:30
https://trac.sagemath.org/ticket/18175#comment:30
<p>
Hi Basile,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:29" title="Comment 29">bpillet</a>:
</p>
<blockquote class="citation">
<p>
As I said, there are case for some fields <strong>K</strong> where <strong>K</strong>analytic is weaker than expected : For example I can make a change of charts x > x<sup>p</sup> over F_p which is actually invertible since x<sup>p</sup> is the identity on F_p but when computing its differential it vanishes identically since px<sup>p1</sup> = 0 in caracteristic p.
</p>
</blockquote>
<p>
Thanks for this example!
</p>
<blockquote class="citation">
<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 <strong>R</strong> and <strong>C</strong> (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.
</p>
</blockquote>
<p>
Yes, you are right, for differentiable manifolds, we should probably limit ourselves to <strong>K</strong>=<strong>C</strong> or <strong>K</strong>=<strong>R</strong> (at least in a first stage). In the refactoring of SageManifolds I am preparing for <a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a>, I leave the base field generic anyway. In the documentation of class <code>TopManifold</code> in <a class="closed ticket" href="https://trac.sagemath.org/ticket/18529" title="enhancement: Topological manifolds: basics (closed: fixed)">#18529</a>, you can see already an example with <strong>K</strong>=<strong>C</strong> (the Riemann sphere as a topological manifold of dimension 1 over <strong>C</strong>).
</p>
TicketegourgoulhonMon, 08 Jun 2015 22:04:07 GMTdescription changed
https://trac.sagemath.org/ticket/18175#comment:31
https://trac.sagemath.org/ticket/18175#comment:31
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/18175?action=diff&version=31">diff</a>)
</li>
</ul>
TicketgitThu, 25 Jun 2015 18:14:07 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:32
https://trac.sagemath.org/ticket/18175#comment:32
<ul>
<li><strong>commit</strong>
changed from <em>95a30aa57fc62f23a884790b57835d107d8bdeef</em> to <em>29a97a7919ce9847c1957111f08114b8947d52ec</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=31ba0b524330c7f7122c08cfa1727fa0f07d24c1"><span class="icon"></span>31ba0b5</a></td><td><code>Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=da729cc7e957de9095eb9cdfe909edb7c4fc5d5e"><span class="icon"></span>da729cc</a></td><td><code>Added more axioms and reworked the manifolds category structure.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=20a71ae59649bec8e1008af3c6a15fade06ddec3"><span class="icon"></span>20a71ae</a></td><td><code>Merge branch 'develop' into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=5418b0f2d0f1bf47ad94c9e1209bd92f0e50de56"><span class="icon"></span>5418b0f</a></td><td><code>Merge branch 'develop' into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=29a97a7919ce9847c1957111f08114b8947d52ec"><span class="icon"></span>29a97a7</a></td><td><code>Minor fixes and reorganizing the manifolds categories.</code>
</td></tr></table>
TickettscrimThu, 25 Jun 2015 18:18:40 GMTstatus, description changed
https://trac.sagemath.org/ticket/18175#comment:33
https://trac.sagemath.org/ticket/18175#comment:33
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/18175?action=diff&version=33">diff</a>)
</li>
</ul>
<p>
Given our discussion, I have reorganized the manifolds category as:
</p>
<pre class="wiki"> Manifolds
/ \
Complex Real

Differentiable

Smooth
/ \
Analytic AlmostComplex
</pre><p>
I've added full doctest coverage and some examples. So ready for proper review.
</p>
<p>
PS  Sorry it took so long to get back to this.
</p>
TicketgitThu, 25 Jun 2015 18:32:03 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:34
https://trac.sagemath.org/ticket/18175#comment:34
<ul>
<li><strong>commit</strong>
changed from <em>29a97a7919ce9847c1957111f08114b8947d52ec</em> to <em>e6076d2a41dbe5e3294c03a95e3e763e60d554ff</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=e6076d2a41dbe5e3294c03a95e3e763e60d554ff"><span class="icon"></span>e6076d2</a></td><td><code>Fixing failing doctests and last tweaks.</code>
</td></tr></table>
TickettscrimThu, 25 Jun 2015 18:32:49 GMT
https://trac.sagemath.org/ticket/18175#comment:35
https://trac.sagemath.org/ticket/18175#comment:35
<p>
Nicolas, question for you. I'm not sure that the subcategories of Manifolds should be subclasses of <code>CategoryWithAxiom</code>. In particular, the <code>Complex</code> and <code>Real</code> and if they should be axioms. Would they still work with <code>FiniteDimensional</code> and <code>Connected</code> axioms?
</p>
TicketegourgoulhonThu, 25 Jun 2015 20:32:12 GMT
https://trac.sagemath.org/ticket/18175#comment:36
https://trac.sagemath.org/ticket/18175#comment:36
<p>
Hi Travis,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:33" title="Comment 33">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Given our discussion, I have reorganized the manifolds category as:
</p>
<pre class="wiki"> Manifolds
/ \
Complex Real

Differentiable

Smooth
/ \
Analytic AlmostComplex
</pre></blockquote>
<p>
It seems to me that <code>Real</code> should not be atop <code>Differentiable</code> in this hierarchy. Indeed, there exist differentiable manifolds over fields other than <strong>R</strong> or <strong>C</strong>: for instance differentiable manifolds over the field of padic numbers, <strong>Q</strong>_p: see e.g. Part II of J.P. Serre's book <em>Lie Algebras and Lie Groups</em> (1992), where differentiable (actually analytic) manifolds over <strong>Q</strong>_p are introduced. For this reason, in the refactoring of SageManifolds I am preparing in <a class="closed ticket" href="https://trac.sagemath.org/ticket/18783" title="enhancement: Differentiable manifolds: basics (closed: fixed)">#18783</a>, 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 <code>Manifolds().Differentiable()</code> without having to assume that the base field is <strong>R</strong>. Similarly, I think that <code>Complex</code> should be a subcategory of <code>Analytic</code>. As you suggest in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:35" title="Comment 35">comment:35</a>, maybe <code>Complex</code> and <code>Real</code> should be axioms, rather than appearing in the above hierarchy...
</p>
<blockquote class="citation">
<p>
I've added full doctest coverage and some examples. So ready for proper review.
</p>
<p>
PS  Sorry it took so long to get back to this.
</p>
</blockquote>
<p>
Thank you for working on this!
</p>
TickettscrimFri, 26 Jun 2015 15:45:45 GMT
https://trac.sagemath.org/ticket/18175#comment:37
https://trac.sagemath.org/ticket/18175#comment:37
<p>
So then you'd do the diagram in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:28" title="Comment 28">comment:28</a>, in contrast to your statement in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:30" title="Comment 30">comment:30</a>? Or did you mean something different in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:30" title="Comment 30">comment:30</a>? I can also make it so the hierarchy is dynamic, in that if <strong>k</strong> 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).
</p>
<p>
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.)
</p>
<p>
As far as making them be axioms vs singleton categories, this is more of an implementation detail.
</p>
TicketegourgoulhonFri, 26 Jun 2015 16:21:36 GMT
https://trac.sagemath.org/ticket/18175#comment:38
https://trac.sagemath.org/ticket/18175#comment:38
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:37" title="Comment 37">tscrim</a>:
</p>
<blockquote class="citation">
<p>
So then you'd do the diagram in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:28" title="Comment 28">comment:28</a>, in contrast to your statement in <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:30" title="Comment 30">comment:30</a>?
</p>
</blockquote>
<p>
Yes this is more or less what I mean. Sorry for the confusion... Actually in preparing the code for differentiable manifolds in <a class="closed ticket" href="https://trac.sagemath.org/ticket/18783" title="enhancement: Differentiable manifolds: basics (closed: fixed)">#18783</a>, I realize that (i) we can allow very easily for a base field different from <strong>R</strong> or <strong>C</strong> and (ii) differentiable manifolds over fields different from <strong>R</strong> or <strong>C</strong> are not so uncommon in the literature, in particular manifolds over <strong>Q</strong>_p. Basically the topological field has to be a complete metric space (as <strong>Q</strong>_p is), so that the notion of differentiability makes sense.
</p>
TickettscrimFri, 26 Jun 2015 17:24:24 GMT
https://trac.sagemath.org/ticket/18175#comment:39
https://trac.sagemath.org/ticket/18175#comment:39
<p>
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 <code>Manifolds</code> 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 <strong>R</strong> variants like <code>RealField</code>.
</p>
TickettscrimSat, 27 Jun 2015 05:25:56 GMT
https://trac.sagemath.org/ticket/18175#comment:40
https://trac.sagemath.org/ticket/18175#comment:40
<p>
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.
</p>
TicketegourgoulhonSat, 27 Jun 2015 14:13:29 GMT
https://trac.sagemath.org/ticket/18175#comment:41
https://trac.sagemath.org/ticket/18175#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:40" title="Comment 40">tscrim</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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. <a class="extlink" href="http://arxiv.org/abs/math/0502168"><span class="icon"></span>math/0502168</a>. Basile, John, Nicolas, do you agree ?
</p>
<p>
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 <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:39" title="Comment 39">comment:39</a>.
</p>
TickettscrimMon, 24 Aug 2015 00:53:12 GMT
https://trac.sagemath.org/ticket/18175#comment:42
https://trac.sagemath.org/ticket/18175#comment:42
<p>
<strong>ping</strong>
</p>
<p>
For the record, I'm okay with general topological fields.
</p>
TicketegourgoulhonMon, 24 Aug 2015 09:33:20 GMT
https://trac.sagemath.org/ticket/18175#comment:43
https://trac.sagemath.org/ticket/18175#comment:43
<p>
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 <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:28" title="Comment 28">comment:28</a>, namely:
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth

Analytic
</pre><p>
leaving the base field generic. Then <code>Real</code> or <code>Complex</code> could be added at any level (as axioms ?) (actually for complex, differentiable implies analytic). What do you think?
</p>
TicketegourgoulhonMon, 24 Aug 2015 09:34:24 GMTreviewer set
https://trac.sagemath.org/ticket/18175#comment:44
https://trac.sagemath.org/ticket/18175#comment:44
<ul>
<li><strong>reviewer</strong>
set to <em>Eric Gourgoulhon</em>
</li>
</ul>
TickettscrimThu, 27 Aug 2015 01:07:22 GMT
https://trac.sagemath.org/ticket/18175#comment:45
https://trac.sagemath.org/ticket/18175#comment:45
<p>
Sounds good to me. I will play around with the <code>Real</code>/<code>Complex</code> axioms and things to get something reasonable.
</p>
<p>
I will take objections and alternative ideas at any point forward too.
</p>
TicketgitSat, 29 Aug 2015 06:51:50 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:46
https://trac.sagemath.org/ticket/18175#comment:46
<ul>
<li><strong>commit</strong>
changed from <em>e6076d2a41dbe5e3294c03a95e3e763e60d554ff</em> to <em>c89b7c6ef04215e33ad810ab0a7936317233723a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=c782e79e689a771eff0547f861a6d10faa9ca2ee"><span class="icon"></span>c782e79</a></td><td><code>Merge branch 'public/categories/topological_metric_spaces18175' into 6.9.b4</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=c89b7c6ef04215e33ad810ab0a7936317233723a"><span class="icon"></span>c89b7c6</a></td><td><code>trac #18175 fixing a typo in the doc</code>
</td></tr></table>
TicketgitThu, 15 Oct 2015 22:50:31 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:47
https://trac.sagemath.org/ticket/18175#comment:47
<ul>
<li><strong>commit</strong>
changed from <em>c89b7c6ef04215e33ad810ab0a7936317233723a</em> to <em>f810aa668c8d0c74ec861e9ab307bedc7777036a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=9a23df17b410858abc671e19d2b90a922614d931"><span class="icon"></span>9a23df1</a></td><td><code>Merge branch 'public/categories/topological_metric_spaces18175' of trac.sagemath.org:sage into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=7c54c8a9a3e8a04f1bd2e6531550adb995ac4442"><span class="icon"></span>7c54c8a</a></td><td><code>Added axiom for Complete and made manifolds a category over a base ring.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=36473057a7c5250f67a53813102e549e1b7f3ed5"><span class="icon"></span>3647305</a></td><td><code>Some cleanup and adding more category information to particular sets.</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=f810aa668c8d0c74ec861e9ab307bedc7777036a"><span class="icon"></span>f810aa6</a></td><td><code>Reworking the category of manifolds.</code>
</td></tr></table>
TickettscrimThu, 15 Oct 2015 22:54:37 GMT
https://trac.sagemath.org/ticket/18175#comment:48
https://trac.sagemath.org/ticket/18175#comment:48
<p>
After much debate with myself, I ended up making the following:
</p>
<pre class="wiki"> Manifolds

Differentiable

Smooth

Analytic
/ \
Almost Complex
</pre><p>
where <code>Complex</code> includes the holomorphic condition. I also added "complete" as an axiom and made some rings/fields into the finer categories they belong to (mainly <code>ZZ</code>, <code>QQ</code>, <code>RR</code>, <code>CC</code> 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).
</p>
TicketegourgoulhonFri, 16 Oct 2015 06:55:34 GMT
https://trac.sagemath.org/ticket/18175#comment:49
https://trac.sagemath.org/ticket/18175#comment:49
<p>
Thank you for this new setting of the manifold categories, very timely regarding <a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a> !
A first quick remark: <code>Almost</code> should be under <code>Smooth</code> since analyticity is not requirred for an almost complex manifold; see e.g. <a class="extlink" href="https://en.wikipedia.org/wiki/Almost_complex_manifold"><span class="icon"></span>https://en.wikipedia.org/wiki/Almost_complex_manifold</a>.
</p>
TicketegourgoulhonFri, 16 Oct 2015 15:47:39 GMTstatus changed
https://trac.sagemath.org/ticket/18175#comment:50
https://trac.sagemath.org/ticket/18175#comment:50
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
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
</p>
TicketgitFri, 16 Oct 2015 15:54:11 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:51
https://trac.sagemath.org/ticket/18175#comment:51
<ul>
<li><strong>commit</strong>
changed from <em>f810aa668c8d0c74ec861e9ab307bedc7777036a</em> to <em>375ff46221b7dcc101536774664b4bb935f99fba</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=375ff46221b7dcc101536774664b4bb935f99fba"><span class="icon"></span>375ff46</a></td><td><code>Fixing doctest failures and letting a few other rings know they are metric spaces.</code>
</td></tr></table>
TickettscrimFri, 16 Oct 2015 15:56:43 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/18175#comment:52
https://trac.sagemath.org/ticket/18175#comment:52
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage6.8</em> to <em>sage6.10</em>
</li>
</ul>
<p>
I made a mistake in my diagram. In the code, almost complex manifolds only imply smooth, not analytic.
</p>
<p>
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 <code>\RR</code> and <code>\CC</code> know that they are also metric spaces.
</p>
<p>
@nthiery Note that I had to make a change to the French Sage book's test.
</p>
TicketegourgoulhonFri, 16 Oct 2015 19:46:25 GMT
https://trac.sagemath.org/ticket/18175#comment:53
https://trac.sagemath.org/ticket/18175#comment:53
<p>
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
</p>
TicketnthieryFri, 16 Oct 2015 22:13:31 GMT
https://trac.sagemath.org/ticket/18175#comment:54
https://trac.sagemath.org/ticket/18175#comment:54
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:52" title="Comment 52">tscrim</a>:
</p>
<blockquote class="citation">
<p>
@nthiery Note that I had to make a change to the French Sage book's test.
</p>
</blockquote>
<p>
I double checked it, and it's fine with me!
</p>
TicketgitSat, 17 Oct 2015 01:21:40 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:55
https://trac.sagemath.org/ticket/18175#comment:55
<ul>
<li><strong>commit</strong>
changed from <em>375ff46221b7dcc101536774664b4bb935f99fba</em> to <em>f8f5b93028708eebb745a1cc92f3b775a760108b</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=8b851a05c2569a55063539bbc8a19937851f4c93"><span class="icon"></span>8b851a0</a></td><td><code>Merge branch 'develop' into public/categories/topological_metric_spaces18175</code>
</td></tr><tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=f8f5b93028708eebb745a1cc92f3b775a760108b"><span class="icon"></span>f8f5b93</a></td><td><code>Fixing last remaining doctests.</code>
</td></tr></table>
TicketegourgoulhonSat, 17 Oct 2015 12:22:57 GMT
https://trac.sagemath.org/ticket/18175#comment:56
https://trac.sagemath.org/ticket/18175#comment:56
<p>
Thanks for the new version. Two remarks:
</p>
<p>
1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?
</p>
<p>
2/ The padic fields implemented in Sage seems not to have been taken into account:
</p>
<pre class="wiki">sage: Qp(5) in Fields().Topological()
False
sage: Qp(5) in Fields().Metric()
False
</pre><p>
One should actually have
</p>
<pre class="wiki">sage: Qp(5) in Fields().Metric().Complete()
True
</pre><p>
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 ?
</p>
TicketgitSat, 17 Oct 2015 14:53:16 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:57
https://trac.sagemath.org/ticket/18175#comment:57
<ul>
<li><strong>commit</strong>
changed from <em>f8f5b93028708eebb745a1cc92f3b775a760108b</em> to <em>041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0"><span class="icon"></span>041a5d1</a></td><td><code>Adding padics to metric spaces and some cleanup.</code>
</td></tr></table>
TickettscrimSat, 17 Oct 2015 15:02:16 GMT
https://trac.sagemath.org/ticket/18175#comment:58
https://trac.sagemath.org/ticket/18175#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:56" title="Comment 56">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?
</p>
</blockquote>
<p>
Yes they should and now they do.
</p>
<blockquote class="citation">
<p>
2/ The padic fields implemented in Sage seems not to have been taken into account:
</p>
<pre class="wiki">sage: Qp(5) in Fields().Topological()
False
sage: Qp(5) in Fields().Metric()
False
</pre><p>
One should actually have
</p>
<pre class="wiki">sage: Qp(5) in Fields().Metric().Complete()
True
</pre><p>
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 ?
</p>
</blockquote>
<p>
I've added them in and I reworked the default <code>dist</code> to use the <code>abs</code> method of the elements. I also made it so that there is a call loop <code>P.metric > E.dist > P.dist > E.abs > P.metric</code> so one just needs to implement one of these methods (<code>P</code> is the parent and <code>E</code> is the element). This is a slight abuse as not all metric spaces have a <code>0</code> (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...
</p>
TicketgitSat, 17 Oct 2015 15:02:25 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:59
https://trac.sagemath.org/ticket/18175#comment:59
<ul>
<li><strong>commit</strong>
changed from <em>041a5d10259ca0ec083a313bd4ad1fe6cfb8d9c0</em> to <em>bfa0cdf3696eadd6c2307f96dd366916746d5366</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=bfa0cdf3696eadd6c2307f96dd366916746d5366"><span class="icon"></span>bfa0cdf</a></td><td><code>One last doc tweak.</code>
</td></tr></table>
TicketgitSat, 17 Oct 2015 15:14:51 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:60
https://trac.sagemath.org/ticket/18175#comment:60
<ul>
<li><strong>commit</strong>
changed from <em>bfa0cdf3696eadd6c2307f96dd366916746d5366</em> to <em>d13c3688328149c08f4efbbcee91a8fd2978d91a</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=d13c3688328149c08f4efbbcee91a8fd2978d91a"><span class="icon"></span>d13c368</a></td><td><code>Fixing doc of metric spaces.</code>
</td></tr></table>
TicketegourgoulhonMon, 19 Oct 2015 13:18:11 GMT
https://trac.sagemath.org/ticket/18175#comment:61
https://trac.sagemath.org/ticket/18175#comment:61
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:58" title="Comment 58">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:56" title="Comment 56">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
1/ The new categories do not appear in the reference manual, in the section "Individual Categories". Shouldn't they ?
</p>
</blockquote>
<p>
Yes they should and now they do.
</p>
</blockquote>
<p>
Very good.
</p>
<blockquote class="citation">
<p>
I've added them in and I reworked the default <code>dist</code> to use the <code>abs</code> method of the elements. I also made it so that there is a call loop <code>P.metric > E.dist > P.dist > E.abs > P.metric</code> so one just needs to implement one of these methods (<code>P</code> is the parent and <code>E</code> is the element). This is a slight abuse as not all metric spaces have a <code>0</code> (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).
</p>
</blockquote>
<p>
The default <code>dist</code> using <code>abs</code> seems reasonable at this stage. Thanks for having added the padic fields.
</p>
<p>
I've merged the last commit of this ticket in all the tickets of <a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a>, replacing the <code>Sets()</code> category by <code>Manifolds(K)</code>, <code>Manifolds(K).Differentiable()</code> or <code>Manifolds(K).Smooth()</code>, with <code>K</code>=<code>RR</code>, <code>QQ</code>, <code>Qp(5)</code> or <code>CC</code>. Everything works well!
</p>
<p>
I've just one last question:
</p>
<p>
In the examples (in <code>src/sage/categories/examples/manifolds.py</code> and <code>src/sage/categories/examples/cw_complexes.py</code>), the parents implement the method <code>an_element</code> and not <code>_an_element_</code> (as advised in the Parent section of the reference manual). Is there any reason for this?
</p>
<p>
and three suggestions of typo corrections:
</p>
<ul><li>in <code>src/sage/categories/manifolds.py</code>, 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"
</li><li>in <code>src/sage/categories/metric_spaces.py</code>, 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"
</li><li>in <code>src/sage/categories/topological_spaces.py</code>, there seems to be an unnecessary import:
<code>from sage.misc.lazy_attribute import lazy_class_attribute</code>
</li></ul>
TicketgitMon, 19 Oct 2015 16:37:06 GMTcommit changed
https://trac.sagemath.org/ticket/18175#comment:62
https://trac.sagemath.org/ticket/18175#comment:62
<ul>
<li><strong>commit</strong>
changed from <em>d13c3688328149c08f4efbbcee91a8fd2978d91a</em> to <em>f6fdd7ddad7fdbef37e7632d628f432891e76acc</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="extlink" href="http://git.sagemath.org/sage.git/commit/?id=f6fdd7ddad7fdbef37e7632d628f432891e76acc"><span class="icon"></span>f6fdd7d</a></td><td><code>Some last little bit of cleanup.</code>
</td></tr></table>
TickettscrimMon, 19 Oct 2015 16:40:55 GMT
https://trac.sagemath.org/ticket/18175#comment:63
https://trac.sagemath.org/ticket/18175#comment:63
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:61" title="Comment 61">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
I've merged the last commit of this ticket in all the tickets of <a class="new ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket (new)">#18528</a>, replacing the <code>Sets()</code> category by <code>Manifolds(K)</code>, <code>Manifolds(K).Differentiable()</code> or <code>Manifolds(K).Smooth()</code>, with <code>K</code>=<code>RR</code>, <code>QQ</code>, <code>Qp(5)</code> or <code>CC</code>. Everything works well!
</p>
</blockquote>
<p>
That's very good to hear!
</p>
<blockquote class="citation">
<p>
I've just one last question:
</p>
<p>
In the examples (in <code>src/sage/categories/examples/manifolds.py</code> and <code>src/sage/categories/examples/cw_complexes.py</code>), the parents implement the method <code>an_element</code> and not <code>_an_element_</code> (as advised in the Parent section of the reference manual). Is there any reason for this?
</p>
</blockquote>
<p>
The reason we have <code>_an_element_</code> was for caching before there was an <code>@cached_method</code>. It is sufficient to implement <code>an_element</code>, especially for example classes. However, I can change if it you feel I should.
</p>
<blockquote class="citation">
<p>
and three suggestions of typo corrections
</p>
</blockquote>
<p>
All done (and some other pyflakes cleanup).
</p>
TicketegourgoulhonMon, 19 Oct 2015 19:57:23 GMTstatus changed
https://trac.sagemath.org/ticket/18175#comment:64
https://trac.sagemath.org/ticket/18175#comment:64
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/18175#comment:63" title="Comment 63">tscrim</a>:
</p>
<blockquote class="citation">
<p>
The reason we have <code>_an_element_</code> was for caching before there was an <code>@cached_method</code>. It is sufficient to implement <code>an_element</code>, especially for example classes. However, I can change if it you feel I should.
</p>
</blockquote>
<p>
No not at all; I was just curious. Thanks for the explanation.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
and three suggestions of typo corrections
</p>
</blockquote>
<p>
All done (and some other pyflakes cleanup).
</p>
</blockquote>
<p>
Thank you for your work ! It's nice to have these categories.
</p>
TickettscrimMon, 19 Oct 2015 23:06:01 GMTdescription changed
https://trac.sagemath.org/ticket/18175#comment:65
https://trac.sagemath.org/ticket/18175#comment:65
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/18175?action=diff&version=65">diff</a>)
</li>
</ul>
<p>
Thanks for doing the review.
</p>
TicketvbraunTue, 20 Oct 2015 22:32:48 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/18175#comment:66
https://trac.sagemath.org/ticket/18175#comment:66
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>public/categories/topological_metric_spaces18175</em> to <em>f6fdd7ddad7fdbef37e7632d628f432891e76acc</em>
</li>
</ul>
Ticket