Sage: Ticket #26344: Nilpotent Lie groups
https://trac.sagemath.org/ticket/26344
<p>
Implementation of nilpotent Lie groups as manifolds with a distinguished global coordinate system (exponential coordinates).
</p>
<p>
Planned features:
</p>
<ul><li>representation of elements in exponential coordinates of the first or second kind
</li><li>multiplication of symbolic points (using the manifold point framework)
</li><li>the frames of left-invariant and right-invariant vector fields
</li><li>the exponential map <code>exp:\mathfrak{g}\to G</code> and the logarithm
</li><li>the adjoint map <code>Ad:G\times \mathfrak{g}\to\mathfrak{g}</code>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/26344
Trac 1.1.6gh-ehakaTue, 25 Sep 2018 06:38:57 GMTcommit, branch set
https://trac.sagemath.org/ticket/26344#comment:1
https://trac.sagemath.org/ticket/26344#comment:1
<ul>
<li><strong>commit</strong>
set to <em>63006ea2885a50569e2b95b24b83db8a7998dbc8</em>
</li>
<li><strong>branch</strong>
set to <em>u/gh-ehaka/nilpotent_lie_groups-26344</em>
</li>
</ul>
<p>
A partial first version is now ready, containing the exponential map, exponential coordinates of the first and second kind and group multiplication. Vector fields and the adjoint map are still completely missing, but I thought it would be good to get a working copy up in case there are already some glaring flaws.
</p>
<p>
In particular, one thing that did not feel quite right was the current method of computing the symbolic group law. The only way I could think of was to extract the structural coefficients of the Lie algebra and to create a new Lie algebra over <code>SR</code> using the same structural coefficients. Two immediate issues of the current approach are
</p>
<ol><li>the overhead of creating a new Lie algebra
</li><li>the original base ring of the Lie algebra needs to admit a coercion into <code>SR</code>
</li></ol><p>
Another thing is how to handle the symbolic group law. Currently it is done by creating two dummy-variables, computing the group law as a vector expression in exponential coordinates (through the BCH formula) and then evaluating the group law by substitution of the dummy-variables.
</p>
<p>
This is still work-in-progress, but I would be happy to hear comments or suggestions.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=1276e0eb34fc6509ef523cedee68803968fa70aa"><span class="icon"></span>1276e0e</a></td><td><code>trac #26080: initial implementation of the BCH formula</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=5972b6b0fbe210019e72e844a1420c7455a7f03f"><span class="icon"></span>5972b6b</a></td><td><code>trac #26080: converted bch iterator to a generator function and added interface for non-nilpotent Lie algebras</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=e12ea13e8fc20f818b6b13afd604e5fb8913f793"><span class="icon"></span>e12ea13</a></td><td><code>trac #26080: efficiency improvements</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=369f7a626c6aa4e362ac3d671ca4e28963d9163d"><span class="icon"></span>369f7a6</a></td><td><code>trac #26080: replaced old stopiteration</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=63006ea2885a50569e2b95b24b83db8a7998dbc8"><span class="icon"></span>63006ea</a></td><td><code>trac #26344: minimal working example of nilpotent Lie groups as manifolds</code>
</td></tr></table>
Ticketgh-ehakaTue, 25 Sep 2018 06:39:34 GMTdependencies set
https://trac.sagemath.org/ticket/26344#comment:2
https://trac.sagemath.org/ticket/26344#comment:2
<ul>
<li><strong>dependencies</strong>
set to <em>#26080</em>
</li>
</ul>
TickettscrimTue, 25 Sep 2018 07:25:37 GMTcc changed
https://trac.sagemath.org/ticket/26344#comment:3
https://trac.sagemath.org/ticket/26344#comment:3
<ul>
<li><strong>cc</strong>
<em>egourgoulhon</em> added
</li>
</ul>
<p>
Eric, I am cc-ing you in case you have any comments.
</p>
<p>
The symbolic ring is usually a bit of a slow beast. it definitely feels wrong to have to have a second copy of the Lie algebra over <code>SR</code>. You probably could just use the structure coeffs info.
</p>
<p>
Anyways, I will think more about this.
</p>
TicketegourgoulhonTue, 25 Sep 2018 21:18:50 GMT
https://trac.sagemath.org/ticket/26344#comment:4
https://trac.sagemath.org/ticket/26344#comment:4
<p>
Good to see that Lie groups are arriving in Sage!
I'll have a look tomorrow, focusing on the <code>SR</code> issue.
</p>
TicketgitWed, 26 Sep 2018 05:56:19 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:5
https://trac.sagemath.org/ticket/26344#comment:5
<ul>
<li><strong>commit</strong>
changed from <em>63006ea2885a50569e2b95b24b83db8a7998dbc8</em> to <em>8e4dfb1820eb636dd5c5b84b3de90bab50445a12</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=8e4dfb1820eb636dd5c5b84b3de90bab50445a12"><span class="icon"></span>8e4dfb1</a></td><td><code>trac #26344: invariant vector fields</code>
</td></tr></table>
TickettscrimWed, 26 Sep 2018 10:04:51 GMT
https://trac.sagemath.org/ticket/26344#comment:6
https://trac.sagemath.org/ticket/26344#comment:6
<p>
I am not sure I agree with caching the <code>*_invariant_frame</code>. I think this is already done by the atlas for the manifold and there is probably not much benefit to having this cached at the top level as not a lot of computation is done in the methods themselves.
</p>
<p>
Another comment is that <code>structure_coefficients</code> should exist anytime the Lie algebra has a basis because of the category. I believe the <code>variable_names()</code> and <code>indices()</code> should not fail either. So I don't see a meaningful exception being thrown.
</p>
<p>
Now that I have enough time, I see why you are using the symbolic ring to create the group law. You are considering things as generic parameters and seeing what the result is. In principle, creating the <code>LieAlgebraWithStructureCoefficients</code> should be relatively quick. It might be better to implement a <code>change_ring()</code> method for the class instead of the helper function (which could have more general use). Unfortunately I don't see a way out of creating that (at least, one that is efficient), but it should not take a lot (well, a disproportionate amount) of memory.
</p>
Ticketgh-ehakaWed, 26 Sep 2018 12:26:35 GMT
https://trac.sagemath.org/ticket/26344#comment:7
https://trac.sagemath.org/ticket/26344#comment:7
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:6" title="Comment 6">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I am not sure I agree with caching the <code>*_invariant_frame</code>. I think this is already done by the atlas for the manifold and there is probably not much benefit to having this cached at the top level as not a lot of computation is done in the methods themselves.
</p>
</blockquote>
<p>
Right, I did not realize there is manifold level caching. I will remove it from here.
</p>
<blockquote class="citation">
<p>
Another comment is that <code>structure_coefficients</code> should exist anytime the Lie algebra has a basis because of the category.
</p>
</blockquote>
<p>
This is a good point, and I should in fact change <code>indices()</code> to <code>basis().keys()</code> as in the category code of <code>structure_coefficients</code>, so it will work regardless within the category.
</p>
<blockquote class="citation">
<p>
It might be better to implement a <code>change_ring()</code> method for the class instead of the helper function (which could have more general use).
</p>
</blockquote>
<p>
Ideally construction of a Lie group would not rely on the Lie algebra having a <code>change_ring()</code> method, but instead only rely on things required/defined in the finite dimensional (nilpotent) Lie algebras with basis category.
</p>
<p>
However it would make sense to by default use <code>change_ring</code> if it exists, and to implement this at least for <code>LieAlgebraWithStructureCoefficients</code>. Then only in the case when <code>change_ring</code> is not defined, the code could fall back to creation of a new Lie algebra using <code>structure_coefficients()</code>.
</p>
<p>
Thanks for the comments!
</p>
TicketgitWed, 26 Sep 2018 16:19:09 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:8
https://trac.sagemath.org/ticket/26344#comment:8
<ul>
<li><strong>commit</strong>
changed from <em>8e4dfb1820eb636dd5c5b84b3de90bab50445a12</em> to <em>61963e06463f59ef392fec1d5e488870788d25c6</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=61963e06463f59ef392fec1d5e488870788d25c6"><span class="icon"></span>61963e0</a></td><td><code>trac #26344: added change_ring to LieAlgebraWithStructureCoefficients and modified symbolic Lie algebra creation</code>
</td></tr></table>
TicketegourgoulhonWed, 26 Sep 2018 22:23:07 GMT
https://trac.sagemath.org/ticket/26344#comment:9
https://trac.sagemath.org/ticket/26344#comment:9
<p>
I gave a first glance: this looks very nice!
</p>
<p>
A very minor remark: in the example shown in line 151 of <code>lie_group.py</code> (as well as in other similar examples), a shortcut for
</p>
<pre class="wiki">sage: list(X[0].components(exp1_frame))
</pre><p>
is
</p>
<pre class="wiki">sage: X[0][exp1_frame,:]
</pre><p>
Maybe you chose the longer version as being more explicit?
Also you can display the components of the vector field <code>X[0]</code> by
</p>
<pre class="wiki">sage: X[0].display(exp1_frame)
X_0 = d/dx_0 - 1/2*x_1 d/dx_2
</pre><p>
Since <code>exp1_frame</code> is the default vector frame on <code>G</code>, this can be shorten to simply
<code>X[0].display()</code>.
</p>
Ticketgh-ehakaThu, 27 Sep 2018 04:36:22 GMT
https://trac.sagemath.org/ticket/26344#comment:10
https://trac.sagemath.org/ticket/26344#comment:10
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:9" title="Comment 9">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
I gave a first glance: this looks very nice!
</p>
<p>
A very minor remark: in the example shown in line 151 of <code>lie_group.py</code> (as well as in other similar examples), a shortcut for
</p>
<pre class="wiki">sage: list(X[0].components(exp1_frame))
</pre><p>
is
</p>
<pre class="wiki">sage: X[0][exp1_frame,:]
</pre><p>
Maybe you chose the longer version as being more explicit?
Also you can display the components of the vector field <code>X[0]</code> by
</p>
<pre class="wiki">sage: X[0].display(exp1_frame)
X_0 = d/dx_0 - 1/2*x_1 d/dx_2
</pre></blockquote>
<p>
This choice was just a consequence of lack of knowledge on my part. Thanks for the advice, this will clean up the doc quite a bit!
</p>
<blockquote class="citation">
<p>
Since <code>exp1_frame</code> is the default vector frame on <code>G</code>, this can be shorten to simply
<code>X[0].display()</code>.
</p>
</blockquote>
<p>
At this point I don't know what should be the default frame. The best sounding options are either the coordinate frame of the default system of coordinates, or the left-invariant frame.
</p>
TicketegourgoulhonThu, 27 Sep 2018 08:42:54 GMT
https://trac.sagemath.org/ticket/26344#comment:11
https://trac.sagemath.org/ticket/26344#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:10" title="Comment 10">gh-ehaka</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Since <code>exp1_frame</code> is the default vector frame on <code>G</code>, this can be shorten to simply
<code>X[0].display()</code>.
</p>
</blockquote>
<p>
At this point I don't know what should be the default frame. The best sounding options are either the coordinate frame of the default system of coordinates, or the left-invariant frame.
</p>
</blockquote>
<p>
In this case, it is probably better to keep the explicit form, i.e. <code>X[0].display(exp1_frame)</code>.
</p>
TicketegourgoulhonThu, 27 Sep 2018 08:58:36 GMT
https://trac.sagemath.org/ticket/26344#comment:12
https://trac.sagemath.org/ticket/26344#comment:12
<p>
In the documentation, maybe you could use the method <code>at()</code> of vector fields to illustrate that the members of <code>G.left_invariant_frame()</code> do obey the definition of a left invariant vector field, for instance:
</p>
<pre class="wiki">sage: L = lie_algebras.Heisenberg(QQ, 1)
sage: G = NilpotentLieGroup(L, 'G'); G
Lie group of Heisenberg algebra of rank 1 over Rational Field
sage: p,q,z = L.basis()
</pre><p>
Let us first introduce a specific element <code>k</code> and generic element <code>g</code> in <code>G</code>:
</p>
<pre class="wiki">sage: k = G.exp(p)*G.exp(q); k
exp(p1 + q1 + 1/2*z)
sage: g = G(G.chart_exp1()[:]); g # a generic element of G
exp(x_0*p1 + x_1*q1 + x_2*z)
</pre><p>
We introduce next the left translation by <code>k</code>:
</p>
<pre class="wiki">sage: L_k = G.diff_map(G, coord_functions=(k*g).coordinates()); L_k
Differentiable map from the Lie group of Heisenberg algebra of rank 1 over Rational Field to itself
sage: L_k.display()
G --> G
(x_0, x_1, x_2) |--> (x_0 + 1, x_1 + 1, -1/2*x_0 + 1/2*x_1 + x_2 + 1/2)
</pre><p>
Then we check that <code>X[0]</code> obeys the definition of a left invariant vector field as follows:
</p>
<pre class="wiki">sage: X = G.left_invariant_frame(); X
Vector frame (G, (X_0,X_1,X_2))
sage: L_k.differential(g)(X[0].at(g)) == X[0].at(L_k(g))
True
</pre><p>
Of course, we have as well
</p>
<pre class="wiki">sage: L_k.differential(g)(X[1].at(g)) == X[1].at(L_k(g))
True
sage: L_k.differential(g)(X[2].at(g)) == X[2].at(L_k(g))
True
</pre><p>
Of course, a full check would require that <code>k</code> is a generic element of <code>G</code>; this is possible, by defining <code>k</code> from symbolic coordinates.
</p>
Ticketgh-ehakaThu, 27 Sep 2018 17:35:16 GMTcommit, branch changed
https://trac.sagemath.org/ticket/26344#comment:13
https://trac.sagemath.org/ticket/26344#comment:13
<ul>
<li><strong>commit</strong>
changed from <em>61963e06463f59ef392fec1d5e488870788d25c6</em> to <em>8a022e85abb13436b8dfc18528f45621309aa4f3</em>
</li>
<li><strong>branch</strong>
changed from <em>u/gh-ehaka/nilpotent_lie_groups-26344</em> to <em>public/groups/nilpotent_lie_groups-26344</em>
</li>
</ul>
<p>
I moved the code over to a public branch so you can feel free to add improvements in if you so wish. I'm also still happy to hear comments and corrections and do the implementation myself as well.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:12" title="Comment 12">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
In the documentation, maybe you could use the method <code>at()</code> of vector fields to illustrate that the members of <code>G.left_invariant_frame()</code> do obey the definition of a left invariant vector field
</p>
</blockquote>
<p>
Thanks for the suggestion, this is indeed a very good demonstration of basic Lie group functionality. I also ended up adding the creation of left/right translations as a prebuilt method as these maps should see heavy use in practice.
</p>
<p>
I have still to add in the methods for the logarithm and adjoint maps, after that I would for the moment be satisfied with the basic Lie group functionality. Or at least I can't think of what it is I am missing.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=8a022e85abb13436b8dfc18528f45621309aa4f3"><span class="icon"></span>8a022e8</a></td><td><code>trac #26344: added methods to create left and right translations and improved docs</code>
</td></tr></table>
TickettscrimThu, 27 Sep 2018 21:54:39 GMT
https://trac.sagemath.org/ticket/26344#comment:14
https://trac.sagemath.org/ticket/26344#comment:14
<p>
There is also no real penalty for having more tickets (at least, I will continue to be reviewing tickets for at least the next year <code>:)</code>). So it doesn't hurt to do things in smaller bites too.
</p>
TicketgitFri, 28 Sep 2018 05:01:42 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:15
https://trac.sagemath.org/ticket/26344#comment:15
<ul>
<li><strong>commit</strong>
changed from <em>8a022e85abb13436b8dfc18528f45621309aa4f3</em> to <em>c16d1f1bac71cbf7f6c21f24cd6f9284a43cebe2</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=c16d1f1bac71cbf7f6c21f24cd6f9284a43cebe2"><span class="icon"></span>c16d1f1</a></td><td><code>trac #26344: conjugation, adjoint and logarithm</code>
</td></tr></table>
Ticketgh-ehakaFri, 28 Sep 2018 05:15:52 GMTstatus changed
https://trac.sagemath.org/ticket/26344#comment:16
https://trac.sagemath.org/ticket/26344#comment:16
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
<p>
The missing parts of the initial set of features I had in mind are now in. It didn't seem right to add the adjoint without adding the conjugation map as well so that is now there as well.
</p>
<p>
At this point I'll move the ticket over to the bug-hunting/improvement phase.
</p>
TicketegourgoulhonFri, 28 Sep 2018 08:34:43 GMT
https://trac.sagemath.org/ticket/26344#comment:17
https://trac.sagemath.org/ticket/26344#comment:17
<p>
I took the liberty of adding a new section "Lie groups" at the manifold metaticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket 1 (closed: fixed)">#18528</a> and put your ticket there. I hope you don't mind.
</p>
TicketegourgoulhonFri, 28 Sep 2018 08:58:39 GMT
https://trac.sagemath.org/ticket/26344#comment:18
https://trac.sagemath.org/ticket/26344#comment:18
<p>
A question came to my mind: at the moment
</p>
<pre class="wiki">sage: L = G.lie_algebra(); L
Heisenberg algebra of rank 1 over Rational Field
sage: T1G = G.tangent_space(G.one()); T1G
Tangent space at exp(0)
</pre><p>
are two different beasts:
</p>
<pre class="wiki">sage: L.category()
Category of finite dimensional nilpotent lie algebras with basis over Rational Field
sage: T1G.category()
Category of finite dimensional vector spaces over Symbolic Ring
sage: L.basis()
Finite family {'p1': p1, 'q1': q1, 'z': z}
sage: T1G.bases()
[Basis (d/dx_0,d/dx_1,d/dx_2) on the Tangent space at exp(0)]
</pre><p>
also as Python objects: <code>L</code> inherits from <code>sage.algebras.lie_algebras.lie_algebra.LieAlgebraWithGenerators</code>, while <code>T1G</code> inherits from <code>sage.tensor.modules.finite_rank_free_module.FiniteRankFreeModule</code>.
</p>
<p>
Would it be worth to implement the canonical vector space isomorphism between the two? Would this be useful? A natural way to do it would be via Sage coercions, i.e. implement at least a coercion from <code>L</code> to <code>T1G</code> (the reverse may not work for vectors with symbolic components). If you think this is worth, this could anyway be postponed to another ticket...
</p>
Ticketgh-ehakaFri, 28 Sep 2018 09:28:03 GMT
https://trac.sagemath.org/ticket/26344#comment:19
https://trac.sagemath.org/ticket/26344#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:17" title="Comment 17">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
I took the liberty of adding a new section "Lie groups" at the manifold metaticket <a class="closed ticket" href="https://trac.sagemath.org/ticket/18528" title="task: SageManifolds metaticket 1 (closed: fixed)">#18528</a> and put your ticket there. I hope you don't mind.
</p>
</blockquote>
<p>
This is perfectly fine by me, organization is good.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:18" title="Comment 18">egourgoulhon</a>:
</p>
<blockquote class="citation">
<p>
Would it be worth to implement the canonical vector space isomorphism between the two? Would this be useful? A natural way to do it would be via Sage coercions, i.e. implement at least a coercion from <code>L</code> to <code>T1G</code> (the reverse may not work for vectors with symbolic components). If you think this is worth, this could anyway be postponed to another ticket...
</p>
</blockquote>
<p>
Yes this makes sense, and at least the simple coercion should be quite immediate to define, since the basis of the Lie algebra and the basis coming from the exponential coordinate frame are already in direct correspondence as lists.
</p>
<p>
It might actually also be nice to give <code>T1G</code> the full Lie algebra structure and upgrade the coercion to one of Lie algebras. Since vector fields already have a Lie bracket operation defined, this should be doable through computation with the left-invariant frame. It would also allow computing symbolic Lie brackets.
</p>
<p>
All of this combined would add up to quite a bit though. I think leaving it to a new ticket would be a good idea.
</p>
TickettscrimFri, 28 Sep 2018 21:48:44 GMT
https://trac.sagemath.org/ticket/26344#comment:20
https://trac.sagemath.org/ticket/26344#comment:20
<p>
While having a coercion would be good, as Eric points out, the mismatch of base rings would force the direction of the coercion <code>L -> T1G</code>. However, because coercions have to preserve structure, <code>T1G</code> would have to carry a Lie algebra structure.
</p>
<p>
Now, this does not have to be a coercion. You could implement the conversions (and have a helper method, such as <code>to_construction_Lie_algebra</code> or some better name) between the two objects. You probably could do this for the tangent space at a generic element since that just corresponds to conjugating by the element.
</p>
<p>
Also as previously stated, that would be good for a followup ticket.
</p>
<p>
For this ticket, the only other things I might want to see are a <code>lie_group</code> method on the Lie algebra (a generic one would raise a <code>NotImplementedError</code> or be an <code>@abstract_method(optional=True)</code>) and an <code>exp</code> method on the Lie algebra element that does <code>self.parent().lie_group().exp(self)</code>.
</p>
TicketgitSat, 29 Sep 2018 05:39:12 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:21
https://trac.sagemath.org/ticket/26344#comment:21
<ul>
<li><strong>commit</strong>
changed from <em>c16d1f1bac71cbf7f6c21f24cd6f9284a43cebe2</em> to <em>7607b8c2a0358502c3796410640db3763ee82967</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=72700a2cbedf866e7f127d801e05d1d215732b14"><span class="icon"></span>72700a2</a></td><td><code>trac #26344: added interface to Lie groups from Lie algebras</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=7607b8c2a0358502c3796410640db3763ee82967"><span class="icon"></span>7607b8c</a></td><td><code>trac #26344: added Lie group _name to _repr_</code>
</td></tr></table>
TicketgitSat, 29 Sep 2018 05:45:03 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:22
https://trac.sagemath.org/ticket/26344#comment:22
<ul>
<li><strong>commit</strong>
changed from <em>7607b8c2a0358502c3796410640db3763ee82967</em> to <em>d3c77ac7b0569691b39e0c4e4f0b3ec4aefbaad4</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=d3c77ac7b0569691b39e0c4e4f0b3ec4aefbaad4"><span class="icon"></span>d3c77ac</a></td><td><code>trac #26344: added name parameter to Lie algebra element method exp</code>
</td></tr></table>
Ticketgh-ehakaSat, 29 Sep 2018 05:55:48 GMT
https://trac.sagemath.org/ticket/26344#comment:23
https://trac.sagemath.org/ticket/26344#comment:23
<p>
I currently set the Lie algebra -> Lie group interface to default to naming the group 'G'. This allows both <code>L.lie_group()</code> and <code>X.exp()</code>, since requiring the name parameter for <code>exp</code> did not seem convenient for use.
</p>
<p>
Should different(ly named) Lie groups of the same Lie algebra have a predefined canonical coercion between each other? Or should these be considered separate objects? I'm not sure about the intended use of the <code>_name</code> parameter when the underlying manifold is the same. In particular, it is clear that
</p>
<pre class="wiki">sage: NilpotentLieGroup(L, 'G') is NilpotentLieGroup(L, 'H')
False
</pre><p>
is desired behavior. Would
</p>
<pre class="wiki">sage: NilpotentLieGroup(L, 'G') == NilpotentLieGroup(L, 'H')
False
</pre><p>
also be desired behavior?
</p>
Ticketgh-ehakaSat, 29 Sep 2018 07:37:54 GMT
https://trac.sagemath.org/ticket/26344#comment:24
https://trac.sagemath.org/ticket/26344#comment:24
<p>
Another question I have is where should the Lie group functionality go in the source and reference?
Currently the source is under <code>sage.groups.lie_group.py</code> and the doc is not linked anywhere since I didn't know where to put it.
</p>
TicketegourgoulhonSat, 29 Sep 2018 12:43:49 GMT
https://trac.sagemath.org/ticket/26344#comment:25
https://trac.sagemath.org/ticket/26344#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:23" title="Comment 23">gh-ehaka</a>:
</p>
<blockquote class="citation">
<p>
I currently set the Lie algebra -> Lie group interface to default to naming the group 'G'. This allows both <code>L.lie_group()</code> and <code>X.exp()</code>, since requiring the name parameter for <code>exp</code> did not seem convenient for use.
</p>
</blockquote>
<p>
I would favor passing the Lie group itself and not the string representing its name as the argument of the <code>exp</code> defined in the element methods of <code>LieAlgebras</code>, i.e.
something like
</p>
<pre class="wiki">def exp(self, lie_group=None):
if not lie_group:
return self.parent().lie_group().exp(self)
return lie_group.exp(self)
</pre><p>
This seems more robust to me, especially at this level (element method of <em>all</em> Lie algebras).
</p>
<blockquote class="citation">
<p>
Should different(ly named) Lie groups of the same Lie algebra have a predefined canonical coercion between each other? Or should these be considered separate objects? I'm not sure about the intended use of the <code>_name</code> parameter when the underlying manifold is the same. In particular, it is clear that
</p>
<pre class="wiki">sage: NilpotentLieGroup(L, 'G') is NilpotentLieGroup(L, 'H')
False
</pre><p>
is desired behavior.
</p>
</blockquote>
<p>
Yes.
</p>
<blockquote class="citation">
<p>
Would
</p>
<pre class="wiki">sage: NilpotentLieGroup(L, 'G') == NilpotentLieGroup(L, 'H')
False
</pre><p>
also be desired behavior?
</p>
</blockquote>
<p>
I would say yes as well (this would be in the same vein as what we have for manifolds), but I am not 100% sure this is the best option.
</p>
TicketegourgoulhonSat, 29 Sep 2018 12:57:26 GMT
https://trac.sagemath.org/ticket/26344#comment:26
https://trac.sagemath.org/ticket/26344#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:24" title="Comment 24">gh-ehaka</a>:
</p>
<blockquote class="citation">
<p>
Another question I have is where should the Lie group functionality go in the source and reference?
Currently the source is under <code>sage.groups.lie_group.py</code> and the doc is not linked anywhere since I didn't know where to put it.
</p>
</blockquote>
<p>
For the reference manual, there are naturally two options:
</p>
<ul><li>a new subsection "Lie groups" of
<a class="ext-link" href="http://doc.sagemath.org/html/en/reference/groups/"><span class="icon"></span>http://doc.sagemath.org/html/en/reference/groups/</a>
</li><li>a new subsection "Lie groups" of <a class="ext-link" href="http://doc.sagemath.org/html/en/reference/manifolds/"><span class="icon"></span>http://doc.sagemath.org/html/en/reference/manifolds/</a>
</li></ul><p>
since Lie groups lie at the intersection of both topics. Depending on which one you choose, I would rename the source file <code>lie_group.py</code> to <code>nilpotent_lie_group.py</code> and place it in the new subdirectory <code>src/sage/groups/lie_groups</code> or <code>src/sage/manifolds/differentiable/lie_groups</code>.
</p>
TickettscrimSat, 29 Sep 2018 23:13:13 GMT
https://trac.sagemath.org/ticket/26344#comment:27
https://trac.sagemath.org/ticket/26344#comment:27
<p>
I would probably put it in with the groups as I think that is there more prominent feature. Moreover, our canonical Lie groups are usually thought of as (matrix) groups, GL, O, U, etc.
</p>
TicketgitSun, 30 Sep 2018 05:06:28 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:28
https://trac.sagemath.org/ticket/26344#comment:28
<ul>
<li><strong>commit</strong>
changed from <em>d3c77ac7b0569691b39e0c4e4f0b3ec4aefbaad4</em> to <em>383a19aea9a8f5d3541557a0f5b698e9338d3300</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=383a19aea9a8f5d3541557a0f5b698e9338d3300"><span class="icon"></span>383a19a</a></td><td><code>trac #26344: lie_gps subfolder and doc fixes</code>
</td></tr></table>
Ticketgh-ehakaSun, 30 Sep 2018 05:13:48 GMT
https://trac.sagemath.org/ticket/26344#comment:29
https://trac.sagemath.org/ticket/26344#comment:29
<p>
I moved the file to <code>sage/groups/lie_gps/nilpotent_lie_group.py</code>. All the other subfolders in groups were <code>*_gps</code> so I copied that folder convention.
</p>
<p>
I added the subsection of Lie groups to the group reference, but it is slightly disturbing to have a separate "Lie groups" subsection when there is the matrix groups heading containing GL and others. On the other hand, the abstract-manifold Lie group doesn't fit under the "Matrix and affine groups" heading, and extending it to something like "Matrix, affine, and Lie groups" seemed even worse. Hopefully this a problem that will solve itself once more Lie group functionality eventually gets added in so that the "Lie groups" heading feels more fleshed out.
</p>
TickettscrimSun, 30 Sep 2018 07:36:40 GMT
https://trac.sagemath.org/ticket/26344#comment:30
https://trac.sagemath.org/ticket/26344#comment:30
<p>
I would argue that this is okay since the other matrix groups do not know they are Lie groups when working over topological fields and also work for a larger class of base fields (e.g., finite fields).
</p>
TicketgitWed, 03 Oct 2018 04:56:54 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:31
https://trac.sagemath.org/ticket/26344#comment:31
<ul>
<li><strong>commit</strong>
changed from <em>383a19aea9a8f5d3541557a0f5b698e9338d3300</em> to <em>790338ea26862e2800068d3a3d7fe35db5e9cfbc</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=790338ea26862e2800068d3a3d7fe35db5e9cfbc"><span class="icon"></span>790338e</a></td><td><code>trac #26344: doc tweaks</code>
</td></tr></table>
Ticketgh-ehakaWed, 03 Oct 2018 05:02:06 GMT
https://trac.sagemath.org/ticket/26344#comment:32
https://trac.sagemath.org/ticket/26344#comment:32
<p>
I changed the docs of <code>NilpotentLieGroup</code> to suggest using the <code>L.lie_group('G')</code> syntax over <code>NilpotentLieGroup(L, 'G')</code>. Having now played around with these for a bit, the former seemed to be the more convenient entry point.
</p>
<p>
Although now the <code>NilpotentLieGroup</code> entry point is not really even relevant as it does not provide any extra functionality. Possibly it could/should be removed from the global namespace? The only benefit I see to keeping it at this moment is being able to use <code>NilpotentLieGroup?</code> to see some usage examples.
</p>
TicketgitWed, 03 Oct 2018 11:05:58 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:33
https://trac.sagemath.org/ticket/26344#comment:33
<ul>
<li><strong>commit</strong>
changed from <em>790338ea26862e2800068d3a3d7fe35db5e9cfbc</em> to <em>e0d909f408fa28a35a351144fff2fee44dd2aa91</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e0d909f408fa28a35a351144fff2fee44dd2aa91"><span class="icon"></span>e0d909f</a></td><td><code>New (sub)catalog of groups.lie, some small code improvements and doc tweaks.</code>
</td></tr></table>
TickettscrimWed, 03 Oct 2018 11:06:34 GMTreviewer set
https://trac.sagemath.org/ticket/26344#comment:34
https://trac.sagemath.org/ticket/26344#comment:34
<ul>
<li><strong>reviewer</strong>
set to <em>Eric Gourgoulhon and Travis Scrimshaw</em>
</li>
</ul>
<p>
It probably should be removed, but it should be a new subcatalog <code>groups.lie</code>. So I did this.
</p>
<p>
I removed the <code>Group.__init__</code> as that was not doing anything useful.
</p>
<p>
I cached <code>chart_exp2</code> and just called that instead of <code>_Exp2</code>.
</p>
<p>
Other misc doc tweaks.
</p>
<p>
If my changes are good, then I think we can set a positive review unless Eric has some more comments.
</p>
TicketgitWed, 03 Oct 2018 14:23:28 GMTcommit changed
https://trac.sagemath.org/ticket/26344#comment:35
https://trac.sagemath.org/ticket/26344#comment:35
<ul>
<li><strong>commit</strong>
changed from <em>e0d909f408fa28a35a351144fff2fee44dd2aa91</em> to <em>b2ef2d9896ca92c139c12781b7d92d2b56397bec</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=b2ef2d9896ca92c139c12781b7d92d2b56397bec"><span class="icon"></span>b2ef2d9</a></td><td><code>trac #26344: avoid creation of exp2 chart in _repr_ + typo fix</code>
</td></tr></table>
Ticketgh-ehakaWed, 03 Oct 2018 14:24:40 GMT
https://trac.sagemath.org/ticket/26344#comment:36
https://trac.sagemath.org/ticket/26344#comment:36
<p>
Ah, I didn't know about the groups catalog, this is a very good solution, thanks! I fixed a typo in the catalog and removed the now empty file <code>lie_gps/all.py</code>
</p>
<p>
I modified the <code>_repr_</code> method of Lie group elements to avoid unnecessarily calling <code>chart_exp2</code> in case the default chart is <code>_Exp1</code>, since the computation is quite expensive. Although the current form is not ideal either, since now if the default coordinate chart is something other than <code>chart_exp2</code> or <code>_Exp1</code>, then it will still unnecessarily compute the transitions to and from exp-2 coordinates. Not sure how to handle this without the <code>_Exp2=None</code> default.
</p>
<p>
Other than that, the changes look good to me.
</p>
TicketegourgoulhonWed, 03 Oct 2018 22:03:52 GMT
https://trac.sagemath.org/ticket/26344#comment:37
https://trac.sagemath.org/ticket/26344#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/26344#comment:34" title="Comment 34">tscrim</a>:
</p>
<blockquote class="citation">
<p>
If my changes are good, then I think we can set a positive review unless Eric has some more comments.
</p>
</blockquote>
<p>
Everything looks good to me, so I agree with the positive review.
Thanks for the nice work!
</p>
TicketegourgoulhonWed, 03 Oct 2018 22:04:20 GMTstatus changed
https://trac.sagemath.org/ticket/26344#comment:38
https://trac.sagemath.org/ticket/26344#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
TicketvbraunFri, 05 Oct 2018 16:56:55 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/26344#comment:39
https://trac.sagemath.org/ticket/26344#comment:39
<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/groups/nilpotent_lie_groups-26344</em> to <em>b2ef2d9896ca92c139c12781b7d92d2b56397bec</em>
</li>
</ul>
TicketjdemeyerWed, 24 Oct 2018 11:52:13 GMTreviewer changed; commit deleted
https://trac.sagemath.org/ticket/26344#comment:40
https://trac.sagemath.org/ticket/26344#comment:40
<ul>
<li><strong>reviewer</strong>
changed from <em>Eric Gourgoulhon and Travis Scrimshaw</em> to <em>Eric Gourgoulhon, Travis Scrimshaw</em>
</li>
<li><strong>commit</strong>
<em>b2ef2d9896ca92c139c12781b7d92d2b56397bec</em> deleted
</li>
</ul>
TicketembraySun, 28 Oct 2018 14:52:23 GMTmilestone changed
https://trac.sagemath.org/ticket/26344#comment:41
https://trac.sagemath.org/ticket/26344#comment:41
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.4</em> to <em>sage-8.5</em>
</li>
</ul>
<p>
This should be re-targeted for 8.5.
</p>
Ticket