Sage: Ticket #25134: Derivation and twisted derivations over rings
https://trac.sagemath.org/ticket/25134
<p>
This ticket implements derivation and <code>theta</code>-derivations over rings.
(It would be useful for implementing general Ore polynomials.)
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/25134
Trac 1.1.6adurandThu, 17 May 2018 14:38:33 GMTbranch set
https://trac.sagemath.org/ticket/25134#comment:1
https://trac.sagemath.org/ticket/25134#comment:1
<ul>
<li><strong>branch</strong>
set to <em>u/adurand/derivation</em>
</li>
</ul>
TicketgitThu, 17 May 2018 14:46:56 GMTcommit set
https://trac.sagemath.org/ticket/25134#comment:2
https://trac.sagemath.org/ticket/25134#comment:2
<ul>
<li><strong>commit</strong>
set to <em>b927acde4b3b54603edd6f55aa58f64ff1bfcaa7</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=b927acde4b3b54603edd6f55aa58f64ff1bfcaa7"><span class="icon"></span>b927acd</a></td><td><code>add method to create derivation in polynomial ring</code>
</td></tr></table>
TicketcarusoTue, 21 Aug 2018 07:35:37 GMTbranch changed
https://trac.sagemath.org/ticket/25134#comment:3
https://trac.sagemath.org/ticket/25134#comment:3
<ul>
<li><strong>branch</strong>
changed from <em>u/adurand/derivation</em> to <em>u/caruso/derivation</em>
</li>
</ul>
TicketcarusoTue, 21 Aug 2018 07:36:31 GMTcommit, description, summary changed
https://trac.sagemath.org/ticket/25134#comment:4
https://trac.sagemath.org/ticket/25134#comment:4
<ul>
<li><strong>commit</strong>
changed from <em>b927acde4b3b54603edd6f55aa58f64ff1bfcaa7</em> to <em>a3de0749d0b734c21a6f18b7567187d37d69fd53</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/25134?action=diff&version=4">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Derivation over rings</em> to <em>Derivation over rings and Ore polynomials</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=a3de0749d0b734c21a6f18b7567187d37d69fd53"><span class="icon"></span>a3de074</a></td><td><code>Initial code written by Amaury Durand</code>
</td></tr></table>
TicketgitWed, 19 Sep 2018 13:00:31 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:5
https://trac.sagemath.org/ticket/25134#comment:5
<ul>
<li><strong>commit</strong>
changed from <em>a3de0749d0b734c21a6f18b7567187d37d69fd53</em> to <em>a222da8eccf0fbd3c4cd989129b8a59b0b46d5b7</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=823594a6a6405639550cb25a293ddfd39f1193ee"><span class="icon"></span>823594a</a></td><td><code>Merge branch 'develop' into t/25134/derivation</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=a222da8eccf0fbd3c4cd989129b8a59b0b46d5b7"><span class="icon"></span>a222da8</a></td><td><code>Implement left Euclidean division</code>
</td></tr></table>
TicketgitThu, 20 Sep 2018 07:00:00 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:6
https://trac.sagemath.org/ticket/25134#comment:6
<ul>
<li><strong>commit</strong>
changed from <em>a222da8eccf0fbd3c4cd989129b8a59b0b46d5b7</em> to <em>532604b87b737b35d7498440af03007fb7e7e137</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=532604b87b737b35d7498440af03007fb7e7e137"><span class="icon"></span>532604b</a></td><td><code>Add a parent for the module of derivations</code>
</td></tr></table>
TicketgitThu, 20 Sep 2018 16:15:32 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:7
https://trac.sagemath.org/ticket/25134#comment:7
<ul>
<li><strong>commit</strong>
changed from <em>532604b87b737b35d7498440af03007fb7e7e137</em> to <em>cf978b3ab69c156b7a344cfec233d8884c705983</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=44f0ca20db735150325dee8c7d0461ddbd6649ae"><span class="icon"></span>44f0ca2</a></td><td><code>Implement twisted derivations</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=cf978b3ab69c156b7a344cfec233d8884c705983"><span class="icon"></span>cf978b3</a></td><td><code>Some documentation</code>
</td></tr></table>
TicketgitThu, 20 Sep 2018 19:13:35 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:8
https://trac.sagemath.org/ticket/25134#comment:8
<ul>
<li><strong>commit</strong>
changed from <em>cf978b3ab69c156b7a344cfec233d8884c705983</em> to <em>51f8b536cadeeaec23c364e03e380b24d865c8d2</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=51f8b536cadeeaec23c364e03e380b24d865c8d2"><span class="icon"></span>51f8b53</a></td><td><code>More doctests</code>
</td></tr></table>
TicketgitThu, 20 Sep 2018 19:14:46 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:9
https://trac.sagemath.org/ticket/25134#comment:9
<ul>
<li><strong>commit</strong>
changed from <em>51f8b536cadeeaec23c364e03e380b24d865c8d2</em> to <em>da467724e892fba5e751bcbb129aba51d4b98de5</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=da467724e892fba5e751bcbb129aba51d4b98de5"><span class="icon"></span>da46772</a></td><td><code>Add author</code>
</td></tr></table>
TicketcarusoThu, 20 Sep 2018 19:16:24 GMTstatus, summary, description, author changed
https://trac.sagemath.org/ticket/25134#comment:10
https://trac.sagemath.org/ticket/25134#comment:10
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>summary</strong>
changed from <em>Derivation over rings and Ore polynomials</em> to <em>Derivation and twisted derivations over rings</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/25134?action=diff&version=10">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Amaury Durand</em> to <em>Amaury Durand, Xavier Caruso</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=da467724e892fba5e751bcbb129aba51d4b98de5"><span class="icon"></span>da46772</a></td><td><code>Add author</code>
</td></tr></table>
TicketgitThu, 20 Sep 2018 19:30:41 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:11
https://trac.sagemath.org/ticket/25134#comment:11
<ul>
<li><strong>commit</strong>
changed from <em>da467724e892fba5e751bcbb129aba51d4b98de5</em> to <em>ec909afd74faa63e2e7c9de85555227051e5588a</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=ec909afd74faa63e2e7c9de85555227051e5588a"><span class="icon"></span>ec909af</a></td><td><code>Add a hash function</code>
</td></tr></table>
TicketgitFri, 21 Sep 2018 06:14:48 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:12
https://trac.sagemath.org/ticket/25134#comment:12
<ul>
<li><strong>commit</strong>
changed from <em>ec909afd74faa63e2e7c9de85555227051e5588a</em> to <em>5b9bab94ce28afb5d263b2f3d37ff3286c290249</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=5b9bab94ce28afb5d263b2f3d37ff3286c290249"><span class="icon"></span>5b9bab9</a></td><td><code>Add doctest for is_zero</code>
</td></tr></table>
TicketcarusoFri, 21 Sep 2018 06:30:13 GMTcc changed
https://trac.sagemath.org/ticket/25134#comment:13
https://trac.sagemath.org/ticket/25134#comment:13
<ul>
<li><strong>cc</strong>
<em>jsrn</em> added
</li>
</ul>
<p>
Hi Johan,
</p>
<p>
With a master student of mine (Amaury Durand), we generalized the notion of Gabidulin codes to any Ore algebra (possibly with derivation) and managed to allow more evaluation points. We are preparing a paper now and we trying to implement our generalized Gabidulin codes in Sage.
</p>
<p>
This ticket implements derivations and theta-derivations over arbitrary commutative rings. It is a first step towards implementing our generalized Gabidulin.
</p>
TicketjsrnFri, 21 Sep 2018 07:47:27 GMT
https://trac.sagemath.org/ticket/25134#comment:14
https://trac.sagemath.org/ticket/25134#comment:14
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:13" title="Comment 13">caruso</a>:
</p>
<blockquote class="citation">
<p>
Hi Johan,
</p>
<p>
With a master student of mine (Amaury Durand), we generalized the notion of Gabidulin codes to any Ore algebra (possibly with derivation) and managed to allow more evaluation points. We are preparing a paper now and we trying to implement our generalized Gabidulin codes in Sage.
</p>
<p>
This ticket implements derivations and theta-derivations over arbitrary commutative rings. It is a first step towards implementing our generalized Gabidulin.
</p>
</blockquote>
<p>
Hi Xavier and Amaury,
</p>
<p>
This looks very promising. I have no experience with theta-derivations over arbitrary commutative rings, but you code seems to explain the definition nicely. I should be able to review the code in the not-too-far-future. I'd like to see a preprint of your paper (if you prefer, in private email), if some of it is ready for consumption, and if you believe it would help my reading of the code.
</p>
<p>
Best,
Johan
</p>
TicketgitFri, 21 Sep 2018 14:12:23 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:15
https://trac.sagemath.org/ticket/25134#comment:15
<ul>
<li><strong>commit</strong>
changed from <em>5b9bab94ce28afb5d263b2f3d37ff3286c290249</em> to <em>f4fed16b7d5fcdcefbc070da60e1e35cdc8c418f</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=f4fed16b7d5fcdcefbc070da60e1e35cdc8c418f"><span class="icon"></span>f4fed16</a></td><td><code>Fix doctest</code>
</td></tr></table>
TickettscrimFri, 21 Sep 2018 23:39:21 GMTstatus, cc, milestone changed; reviewer set
https://trac.sagemath.org/ticket/25134#comment:16
https://trac.sagemath.org/ticket/25134#comment:16
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Travis Scrimshaw</em>
</li>
<li><strong>cc</strong>
<em>tscrim</em> added
</li>
<li><strong>milestone</strong>
changed from <em>sage-8.2</em> to <em>sage-8.4</em>
</li>
</ul>
<p>
This is a good advancement and looks in good shape. I have a few comments and suggestions.
</p>
<p>
The set of all derivations forms a Lie algebra with <code>[X, Y] = X*Y - Y*X</code>, which Sage has support for. So for untwisted derivations, it should be in the category of <code>LieAlgebras</code>. Let me know if you have any questions about adding this. (The twisted derivations forms what is known as a hom-Lie algebra, where the Jacobi relation also needs to be twisted.)
</p>
<p>
Additionally, when the ring is a finite-dimensional algebra with an explicit basis, we can compute a basis for the derivation module in terms of matrices:
</p>
<pre class="wiki">sage: E.<x,y> = ExteriorAlgebra(QQ)
sage: E.derivations_basis()
(
[0 0 0 0] [0 0 0 0] [0 0 0 0] [0 0 0 0] [0 0 0 0] [0 0 0 0]
[0 1 0 0] [0 0 1 0] [0 0 0 0] [0 0 0 0] [0 0 0 0] [0 0 0 0]
[0 0 0 0] [0 0 0 0] [0 1 0 0] [0 0 1 0] [0 0 0 0] [0 0 0 0]
[0 0 0 1], [0 0 0 0], [0 0 0 0], [0 0 0 1], [0 1 0 0], [0 0 1 0]
)
</pre><p>
Although incorporating that is something that could easily be on a followup ticket as it will likely require a bit of extending your current implementation.
</p>
<p>
A few quick comments from reading the browsing the code:
</p>
<ul><li>You should not set <code>self.element_class</code> attribute, but instead set <code>self.Element</code> (the <code>Parent.__init__</code> ends up creating the new subclass <code>element_class</code> using stuff from the category).
</li><li>Python convention is error messages do not start with a capital letter.
</li><li>Remove the first <code>::</code> here:
<pre class="wiki">::
Twisted derivations and handled similarly::
</pre></li><li><code>Returns</code> -> <code>Return</code>.
</li><li><code>``n``th</code> -> <code>``n``-th</code> as otherwise it does not get parsed correctly.
</li><li><code>``n`` - an integer (default: ``0``)</code> -> <code>-``n`` -- integer (default: ``0``)</code>
</li><li>It might actually be good to have <code>RingDerivation</code> still inherit from <code>(Ring)Map</code> as the composition just becomes a formal composition of maps in the homspace (IIRC the default behavior). Plus it allows for natural functionality.
</li><li>I think it would be better to remove <code>derivation_twisted</code> and just have an extra input to <code>derivation</code>. It will have better localization of code and documentation and match the semantic of <code>derivation_module</code>.
</li></ul>
TicketcarusoSat, 22 Sep 2018 08:19:23 GMT
https://trac.sagemath.org/ticket/25134#comment:17
https://trac.sagemath.org/ticket/25134#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:14" title="Comment 14">jsrn</a>:
</p>
<blockquote class="citation">
<p>
This looks very promising. I have no experience with theta-derivations over arbitrary commutative rings, but you code seems to explain the definition nicely. I should be able to review the code in the not-too-far-future.
</p>
</blockquote>
<p>
Great!
</p>
<blockquote class="citation">
<p>
I'd like to see a preprint of your paper (if you prefer, in private email), if some of it is ready for consumption, and if you believe it would help my reading of the code.
</p>
</blockquote>
<p>
OK, we'll send it to you... as soon as it is ready.
</p>
TicketcarusoSat, 22 Sep 2018 08:37:50 GMT
https://trac.sagemath.org/ticket/25134#comment:18
https://trac.sagemath.org/ticket/25134#comment:18
<p>
Thanks Travis for your comments.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:16" title="Comment 16">tscrim</a>:
</p>
<blockquote class="citation">
<p>
The set of all derivations forms a Lie algebra with <code>[X, Y] = X*Y - Y*X</code>, which Sage has support for. So for untwisted derivations, it should be in the category of <code>LieAlgebras</code>. Let me know if you have any questions about adding this. (The twisted derivations forms what is known as a hom-Lie algebra, where the Jacobi relation also needs to be twisted.)
</p>
</blockquote>
<p>
Good point.
I'll add it. (I think I can do it by myself but I'll ask you if I have questions.)
</p>
<p>
Are there support in Sage for hom-Lie algebras?
</p>
<blockquote class="citation">
<ul><li>You should not set <code>self.element_class</code> attribute, but instead set <code>self.Element</code> (the <code>Parent.__init__</code> ends up creating the new subclass <code>element_class</code> using stuff from the category).
</li></ul></blockquote>
<p>
Ah, OK.
</p>
<blockquote class="citation">
<ul><li>Python convention is error messages do not start with a capital letter.
</li></ul></blockquote>
<p>
Really? Is it the Sage convention as well?
I ask the question because I remember that, one time, somebody told me that I should capitalize my error messages.
</p>
<blockquote class="citation">
<ul><li>It might actually be good to have <code>RingDerivation</code> still inherit from <code>(Ring)Map</code> as the composition just becomes a formal composition of maps in the homspace (IIRC the default behavior). Plus it allows for natural functionality.
</li></ul></blockquote>
<p>
Actually, I already tried to inherit from <code>RingMap</code> but had some troubles. But I can try harder :-)
</p>
<blockquote class="citation">
<ul><li>I think it would be better to remove <code>derivation_twisted</code> and just have an extra input to <code>derivation</code>. It will have better localization of code and documentation and match the semantic of <code>derivation_module</code>.
</li></ul></blockquote>
<p>
The semantic of <code>derivation</code> is a bit different from that of <code>derivation_twisted</code>. It's the reason why I've implemented two distinct methods.
</p>
<p>
By the way, I just realized that my current code works almost only for polynomial algebras. In particular, it does not work for quotients of polynomial algebras: <code>d/dx</code> does not define a derivation over <code>A[x]/P(x)</code> but it does define a derivation from <code>A[x]/P(x)</code> to <code>A[x]/(P(x),P'(x))</code>. I don't know what is the best way to fix this: I can certainly move the method <code>derivation</code> to the classes <code>PolynomialRing_general</code>, <code>MPolynomialRing_base</code> and <code>FractionField_generic</code>) but this implies code duplication. Otherwise, I can leave it in the class <code>Ring</code> but check if <code>self</code> is an instance of those classes. I don't know if it's a good practice.
</p>
TicketcarusoSat, 22 Sep 2018 13:52:25 GMT
https://trac.sagemath.org/ticket/25134#comment:19
https://trac.sagemath.org/ticket/25134#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:18" title="Comment 18">caruso</a>:
</p>
<blockquote class="citation">
<p>
By the way, I just realized that my current code works almost only for polynomial algebras. In particular, it does not work for quotients of polynomial algebras: <code>d/dx</code> does not define a derivation over <code>A[x]/P(x)</code> but it does define a derivation from <code>A[x]/P(x)</code> to <code>A[x]/(P(x),P'(x))</code>. I don't know what is the best way to fix this: I can certainly move the method <code>derivation</code> to the classes <code>PolynomialRing_general</code>, <code>MPolynomialRing_base</code> and <code>FractionField_generic</code>) but this implies code duplication. Otherwise, I can leave it in the class <code>Ring</code> but check if <code>self</code> is an instance of those classes. I don't know if it's a good practice.
</p>
</blockquote>
<p>
In fact, I think I can test it in the <code>__init</code> function of <code>RingDerivation</code>.
So everything's fine.
</p>
TickettscrimSat, 22 Sep 2018 14:17:18 GMT
https://trac.sagemath.org/ticket/25134#comment:20
https://trac.sagemath.org/ticket/25134#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:18" title="Comment 18">caruso</a>:
</p>
<blockquote class="citation">
<p>
Thanks Travis for your comments.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:16" title="Comment 16">tscrim</a>:
</p>
<blockquote class="citation">
<p>
The set of all derivations forms a Lie algebra with <code>[X, Y] = X*Y - Y*X</code>, which Sage has support for. So for untwisted derivations, it should be in the category of <code>LieAlgebras</code>. Let me know if you have any questions about adding this. (The twisted derivations forms what is known as a hom-Lie algebra, where the Jacobi relation also needs to be twisted.)
</p>
</blockquote>
<p>
Good point.
I'll add it. (I think I can do it by myself but I'll ask you if I have questions.)
</p>
</blockquote>
<p>
Thank you.
</p>
<blockquote class="citation">
<p>
Are there support in Sage for hom-Lie algebras?
</p>
</blockquote>
<p>
Currently no. It is not hard to add generic support in the form of having a category and lifting the <code>bracket</code> methods. However, I am not sure how much of the general theory (and hence code) could be lifted from Lie algebras to hom-Lie algebras.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Python convention is error messages do not start with a capital letter.
</li></ul></blockquote>
<p>
Really? Is it the Sage convention as well?
I ask the question because I remember that, one time, somebody told me that I should capitalize my error messages.
</p>
</blockquote>
<p>
Yes. Whomever said otherwise was mistaken (granted there are exceptions when the message needs to be really long, but these are quite rare). At least, that is the consensus I have understood.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>It might actually be good to have <code>RingDerivation</code> still inherit from <code>(Ring)Map</code> as the composition just becomes a formal composition of maps in the homspace (IIRC the default behavior). Plus it allows for natural functionality.
</li></ul></blockquote>
<p>
Actually, I already tried to inherit from <code>RingMap</code> but had some troubles. But I can try harder :-)
</p>
</blockquote>
<p>
If it was giving you difficulties, then feel free to drop it. It is not a big issue. I am happy to help try and debug things here as well.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>I think it would be better to remove <code>derivation_twisted</code> and just have an extra input to <code>derivation</code>. It will have better localization of code and documentation and match the semantic of <code>derivation_module</code>.
</li></ul></blockquote>
<p>
The semantic of <code>derivation</code> is a bit different from that of <code>derivation_twisted</code>. It's the reason why I've implemented two distinct methods.
</p>
</blockquote>
<p>
Somewhat, but it feels a little artificial. You could just have a keyword only argument of <code>twist</code>, which I feel is quite natural to have. However, I don't feel that strongly about it, so if you would rather keep the current constructs, then it is fine by me.
</p>
<blockquote class="citation">
<p>
By the way, I just realized that my current code works almost only for polynomial algebras. In particular, it does not work for quotients of polynomial algebras: <code>d/dx</code> does not define a derivation over <code>A[x]/P(x)</code> but it does define a derivation from <code>A[x]/P(x)</code> to <code>A[x]/(P(x),P'(x))</code>. I don't know what is the best way to fix this: I can certainly move the method <code>derivation</code> to the classes <code>PolynomialRing_general</code>, <code>MPolynomialRing_base</code> and <code>FractionField_generic</code>) but this implies code duplication. Otherwise, I can leave it in the class <code>Ring</code> but check if <code>self</code> is an instance of those classes. I don't know if it's a good practice.
</p>
</blockquote>
<p>
I feel like it should work with quotients: If a map is a derivation in the ambient space, so when taking the quotient (which is functorial), you are preserving the equality. Perhaps I am over-simplifying things. I am guessing you have an explicit example in mind?
</p>
TicketgitSat, 22 Sep 2018 22:14:22 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:21
https://trac.sagemath.org/ticket/25134#comment:21
<ul>
<li><strong>commit</strong>
changed from <em>f4fed16b7d5fcdcefbc070da60e1e35cdc8c418f</em> to <em>568ba75735f31d338542aafa76b5e90204cf949d</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=2bb4bbdea7d4befb3734b40466d2274cf1e77548"><span class="icon"></span>2bb4bbd</a></td><td><code>Small fixes</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=568ba75735f31d338542aafa76b5e90204cf949d"><span class="icon"></span>568ba75</a></td><td><code>Merge branch 'develop' into t/25134/derivation</code>
</td></tr></table>
TicketcarusoSat, 22 Sep 2018 22:28:47 GMT
https://trac.sagemath.org/ticket/25134#comment:22
https://trac.sagemath.org/ticket/25134#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:20" title="Comment 20">tscrim</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
By the way, I just realized that my current code works almost only for polynomial algebras. In particular, it does not work for quotients of polynomial algebras: <code>d/dx</code> does not define a derivation over <code>A[x]/P(x)</code> but it does define a derivation from <code>A[x]/P(x)</code> to <code>A[x]/(P(x),P'(x))</code>. I don't know what is the best way to fix this: I can certainly move the method <code>derivation</code> to the classes <code>PolynomialRing_general</code>, <code>MPolynomialRing_base</code> and <code>FractionField_generic</code>) but this implies code duplication. Otherwise, I can leave it in the class <code>Ring</code> but check if <code>self</code> is an instance of those classes. I don't know if it's a good practice.
</p>
</blockquote>
<p>
I feel like it should work with quotients: If a map is a derivation in the ambient space, so when taking the quotient (which is functorial), you are preserving the equality. Perhaps I am over-simplifying things. I am guessing you have an explicit example in mind?
</p>
</blockquote>
<p>
Well, if <code>A = B (mod P)</code>, we can write <code>A = B + PQ</code> and taking the derivative, one gets <code>A' = B' + P'Q + PQ'</code> meaning that <code>A' = B' (mod (P,P'))</code> but in general <code>A' != B' (mod P)</code>.
</p>
<p>
For a concrete example, take <code>P = X^n</code> and observe that the derivative of a polynomial defined modulo <code>X^n</code> is a polynomial defined modulo <code>X^(n-1)</code> (basically, we shift coefficients).
</p>
TickettscrimSat, 22 Sep 2018 23:30:16 GMT
https://trac.sagemath.org/ticket/25134#comment:23
https://trac.sagemath.org/ticket/25134#comment:23
<p>
Ah, I know where I was going wrong: taking a quotient by a fixed ideal is not functorial, you need the ideal to be in the kernel.
</p>
TicketgitTue, 25 Sep 2018 18:19:46 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:24
https://trac.sagemath.org/ticket/25134#comment:24
<ul>
<li><strong>commit</strong>
changed from <em>568ba75735f31d338542aafa76b5e90204cf949d</em> to <em>d380337fb98e26781a6099c731ba971305009bf4</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=d380337fb98e26781a6099c731ba971305009bf4"><span class="icon"></span>d380337</a></td><td><code>New version with less bugs (e.g. derivations over iterated polynomial rings now works) and more functionalities (Lie bracket, pth power, etc.)</code>
</td></tr></table>
TicketcarusoTue, 25 Sep 2018 18:29:31 GMTstatus changed
https://trac.sagemath.org/ticket/25134#comment:25
https://trac.sagemath.org/ticket/25134#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I've redesigned the way derivations are handled in order to fix the bug I pointed out above (and some others) and addressed some of your remarks.
</p>
<p>
I tried again to make <code>RingDerivation</code> inherit from <code>RingMap</code> but it's tricky because it implies that the parent <code>RingDerivationModule</code> must inherit from <code>Homset</code>, which now implies to define a method <code>homset_category</code> specifying in which category are the elements (i.e. the derivations). Since the derivations are not the morphims in any category (they are not stable under composition), I gave up.
</p>
<p>
Something we can implement is two methods <code>precompose</code> and <code>postcompose</code> that precompose/postcompose a derivation with a ring homomorphism (in which case, the result is again a derivation). The tricky point is that we get this way a derivation from a ring <code>A</code> to <code>B</code> where <code>B</code> is a <code>A</code>-algebra but the defining morphism might not be the coercion morphism (if it exists). So we should have support for this (which is good thing to have I think but needs some extra work).
</p>
TicketgitTue, 25 Sep 2018 18:39:43 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:26
https://trac.sagemath.org/ticket/25134#comment:26
<ul>
<li><strong>commit</strong>
changed from <em>d380337fb98e26781a6099c731ba971305009bf4</em> to <em>b588b092e5e499bfe312586c71578da7b4842306</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=b588b092e5e499bfe312586c71578da7b4842306"><span class="icon"></span>b588b09</a></td><td><code>Fix doctest</code>
</td></tr></table>
TicketgitTue, 25 Sep 2018 23:25:39 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:27
https://trac.sagemath.org/ticket/25134#comment:27
<ul>
<li><strong>commit</strong>
changed from <em>b588b092e5e499bfe312586c71578da7b4842306</em> to <em>77dce7bb150bd0cb51d74913a36f875726b8f8bb</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=e0377835aa2bbcdf732feb0fea2c6d779c83d073"><span class="icon"></span>e037783</a></td><td><code>Implement comparison between derivations</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=5b1cb68cec9be03439a9eaf52e4fef3f01acea83"><span class="icon"></span>5b1cb68</a></td><td><code>Add support for algebras defined by any ring homomorphism</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=0017f9625f4109b777948b8cf2b0c2a77ff2c31d"><span class="icon"></span>0017f96</a></td><td><code>Add precompose and postcompose</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=77dce7bb150bd0cb51d74913a36f875726b8f8bb"><span class="icon"></span>77dce7b</a></td><td><code>Check that the morphisms passed to the methods precompose/postcompose are indeed ring homomorphisms</code>
</td></tr></table>
TicketcarusoTue, 25 Sep 2018 23:26:23 GMT
https://trac.sagemath.org/ticket/25134#comment:28
https://trac.sagemath.org/ticket/25134#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:25" title="Comment 25">caruso</a>:
</p>
<blockquote class="citation">
<p>
Something we can implement is two methods <code>precompose</code> and <code>postcompose</code> that precompose/postcompose a derivation with a ring homomorphism (in which case, the result is again a derivation). The tricky point is that we get this way a derivation from a ring <code>A</code> to <code>B</code> where <code>B</code> is a <code>A</code>-algebra but the defining morphism might not be the coercion morphism (if it exists). So we should have support for this (which is good thing to have I think but needs some extra work).
</p>
</blockquote>
<p>
OK. I've implemented this.
</p>
TickettscrimWed, 26 Sep 2018 01:03:27 GMT
https://trac.sagemath.org/ticket/25134#comment:29
https://trac.sagemath.org/ticket/25134#comment:29
<p>
Thank you for adding the Lie algebra support and your additional changes and experiments. It is a little sad the <code>Morphism</code> framework is not working here, but that is a limitation of the current implementation. This should be my last group of questions.
</p>
<p>
I think there is something we should be careful about in the module doc. If <code>A</code> is not a commutative ring, then <code>B</code> needs to be an <code>A</code>-bimodule (not necessarily an algebra) to be a derivation. However, there is a left and a right action of <code>A</code> on <code>B</code> used in the definition. (With the code itself, this is not a problem because you enforce <code>A</code> to be commutative.)
</p>
<p>
I feel like, at least for ease of maintenance, it would be better for <code>basis</code> to return <code>self._basis</code> even if it is <code>_gens</code>. It helps keep these as separate constructs and allows us later to take a larger generator set and then reduce it to a basis.
</p>
<p>
You need to add <code>derivation.py</code> to the documentation.
</p>
<p>
Replace <code>_cmp_</code> with <code>_richcmp_</code> as this will make it Python3 compatible.
</p>
<p>
It is better to use
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">-self.parent().codomain()(0)
</span><span class="gi">+self.parent().codomain().zero()
</span></pre></div></div><p>
since the latter is cached and avoids coercion/conversion.
</p>
<p>
I think your elements need to implement a <code>monomial_coefficients()</code> method, where the output is a <code>dict</code> whose keys are the basis indices and the values are the corresponding coefficients.
</p>
<p>
I think <code>(dual_)basis</code> should return a <code>Family</code> (or a <code>Sequence</code>, but this has a more limited feature set) to be consistent with other parts of Sage in <code>ModulesWithBasis</code>.
</p>
<p>
Every <code>__init__</code> should have a <code>TestSuite(foo).run()</code> call. This is usually a good way to catch bugs and implementation requirements from the category.
</p>
<p>
I think a better <code>__hash__</code> test would be
</p>
<pre class="wiki">sage: hash(M) == hash((M.domain(), M.codomain(), M.twisting_morphism())
True
</pre><p>
as it shows that the hash works and what it should be equal to.
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">-``n`` - an integer (default: ``0``)
</span><span class="gi">+-``n`` -- an integer (default: ``0``)
</span></pre></div></div><p>
Instead of <code>self(x)</code>, why not do <code>self.element_class(self, x)</code>? Granted, it is not going to make a big difference in speed, but I think it is a little better because it is more direct.
</p>
<p>
In the same vein, for the arithmetic operations, it is faster to do, e.g.,
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">-return self.parent()(self._scalar - other._scalar)
</span><span class="gi">+return type(self)(self.parent(), self._scalar - other._scalar)
</span></pre></div></div><p>
Why all the same definition of <code>__hash__</code>? You are not doing a new <code>__eq__</code>/<code>__richcmp__</code>, so there should not be a need to do this. Why not have this be in the ABC and override when you need to?
</p>
<p>
General question, how much speed do you think you need with these elements? It might be worthwhile to consider Cythonizing the elements.
</p>
TicketgitWed, 26 Sep 2018 16:05:54 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:30
https://trac.sagemath.org/ticket/25134#comment:30
<ul>
<li><strong>commit</strong>
changed from <em>77dce7bb150bd0cb51d74913a36f875726b8f8bb</em> to <em>c9deb7f95efb4d87907c27b738027be838578f23</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=c9deb7f95efb4d87907c27b738027be838578f23"><span class="icon"></span>c9deb7f</a></td><td><code>Address some of Travis' comments</code>
</td></tr></table>
TicketcarusoWed, 26 Sep 2018 16:15:31 GMT
https://trac.sagemath.org/ticket/25134#comment:31
https://trac.sagemath.org/ticket/25134#comment:31
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:29" title="Comment 29">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I think there is something we should be careful about in the module doc. If <code>A</code> is not a commutative ring, then <code>B</code> needs to be an <code>A</code>-bimodule (not necessarily an algebra) to be a derivation. However, there is a left and a right action of <code>A</code> on <code>B</code> used in the definition. (With the code itself, this is not a problem because you enforce <code>A</code> to be commutative.)
</p>
</blockquote>
<p>
What do you propose concretely?
I can add a doctest demonstrating that derivations are not supported over noncommutative rings. How does it sound?
</p>
<blockquote class="citation">
<p>
I feel like, at least for ease of maintenance, it would be better for <code>basis</code> to return <code>self._basis</code> even if it is <code>_gens</code>. It helps keep these as separate constructs and allows us later to take a larger generator set and then reduce it to a basis.
</p>
</blockquote>
<p>
Sure!
</p>
<blockquote class="citation">
<p>
You need to add <code>derivation.py</code> to the documentation.
</p>
</blockquote>
<p>
I'm unsure what I'm supposed to do exactlt? It is fine now?
</p>
<blockquote class="citation">
<p>
Replace <code>_cmp_</code> with <code>_richcmp_</code> as this will make it Python3 compatible.
</p>
</blockquote>
<p>
OK. So far, I've just implemented <code>==</code> and <code>!=</code>. Should I implement the other rich comparison operators as well? (But I don't know how they should behave.)
</p>
<blockquote class="citation">
<p>
It is better to use
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">-self.parent().codomain()(0)
</span><span class="gi">+self.parent().codomain().zero()
</span></pre></div></div><p>
since the latter is cached and avoids coercion/conversion.
</p>
</blockquote>
<p>
OK.
</p>
<blockquote class="citation">
<p>
I think your elements need to implement a <code>monomial_coefficients()</code> method, where the output is a <code>dict</code> whose keys are the basis indices and the values are the corresponding coefficients.
</p>
</blockquote>
<p>
Done.
</p>
<blockquote class="citation">
<p>
I think <code>(dual_)basis</code> should return a <code>Family</code> (or a <code>Sequence</code>, but this has a more limited feature set) to be consistent with other parts of Sage in <code>ModulesWithBasis</code>.
</p>
</blockquote>
<p>
Well, ok for returning a <code>Family</code>...
</p>
<blockquote class="citation">
<p>
Every <code>__init__</code> should have a <code>TestSuite(foo).run()</code> call. This is usually a good way to catch bugs and implementation requirements from the category.
</p>
</blockquote>
<p>
I'll do it.
</p>
<blockquote class="citation">
<p>
I think a better <code>__hash__</code> test would be
</p>
<pre class="wiki">sage: hash(M) == hash((M.domain(), M.codomain(), M.twisting_morphism())
True
</pre><p>
as it shows that the hash works and what it should be equal to.
</p>
</blockquote>
<p>
OK.
</p>
<blockquote class="citation">
<div class="wiki-code"><div class="code"><pre><span class="gd">-``n`` - an integer (default: ``0``)
</span><span class="gi">+-``n`` -- an integer (default: ``0``)
</span></pre></div></div></blockquote>
<p>
Done.
</p>
<blockquote class="citation">
<p>
Instead of <code>self(x)</code>, why not do <code>self.element_class(self, x)</code>? Granted, it is not going to make a big difference in speed, but I think it is a little better because it is more direct.
</p>
</blockquote>
<p>
I've changed this.
</p>
<blockquote class="citation">
<p>
In the same vein, for the arithmetic operations, it is faster to do, e.g.,
</p>
<div class="wiki-code"><div class="code"><pre><span class="gd">-return self.parent()(self._scalar - other._scalar)
</span><span class="gi">+return type(self)(self.parent(), self._scalar - other._scalar)
</span></pre></div></div></blockquote>
<p>
OK. I'll change this.
</p>
<blockquote class="citation">
<p>
Why all the same definition of <code>__hash__</code>? You are not doing a new <code>__eq__</code>/<code>__richcmp__</code>, so there should not be a need to do this. Why not have this be in the ABC and override when you need to?
</p>
</blockquote>
<p>
It seems that you must have to redefine <code>__hash__</code> in each class even if the code does not change (otherwise I got an error). I don't know why.
</p>
<blockquote class="citation">
<p>
General question, how much speed do you think you need with these elements? It might be worthwhile to consider Cythonizing the elements.
</p>
</blockquote>
<p>
For now, I'm not that concerned with speed. But on the other hand, I'm aware that my code is rather slow (especially for iteration polynomial rings). I will probably (one day) consider Cythonizing derivations but, except if you strongly disagree, it will be for another ticket.
</p>
TickettscrimWed, 26 Sep 2018 23:01:09 GMT
https://trac.sagemath.org/ticket/25134#comment:32
https://trac.sagemath.org/ticket/25134#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:31" title="Comment 31">caruso</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/25134#comment:29" title="Comment 29">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I think there is something we should be careful about in the module doc. If <code>A</code> is not a commutative ring, then <code>B</code> needs to be an <code>A</code>-bimodule (not necessarily an algebra) to be a derivation. However, there is a left and a right action of <code>A</code> on <code>B</code> used in the definition. (With the code itself, this is not a problem because you enforce <code>A</code> to be commutative.)
</p>
</blockquote>
<p>
What do you propose concretely?
I can add a doctest demonstrating that derivations are not supported over noncommutative rings. How does it sound?
</p>
</blockquote>
<p>
I don't think it needs a doctest since for the actual implementation you say commutative ring. I think it is sufficient to just replace "algebra over <code>A</code>" with "<code>A</code>-bimodule" in the top-level docstring.
</p>
<p>
It might be worthwhile mentioning somewhere (maybe <code>RingDerivationModule</code>, but maybe elsewhere) that when <code>B = A</code>, then the set of (twisted) derivations has a (hom-)Lie algebra structure. However, I am bias because I like Lie algebras. :)
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
You need to add <code>derivation.py</code> to the documentation.
</p>
</blockquote>
<p>
I'm unsure what I'm supposed to do exactlt? It is fine now?
</p>
</blockquote>
<p>
Yes, that is what was missing.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Replace <code>_cmp_</code> with <code>_richcmp_</code> as this will make it Python3 compatible.
</p>
</blockquote>
<p>
OK. So far, I've just implemented <code>==</code> and <code>!=</code>. Should I implement the other rich comparison operators as well? (But I don't know how they should behave.)
</p>
</blockquote>
<p>
No, you shouldn't. In fact, that is once of the nice things about <code>_richcmp_</code> is you do not need other comparisons. You can just return a <code>NotImplemented</code>. Although, you could just do
</p>
<pre class="wiki">from sage.structure.richcmp import richcmp # put this import at the top level
return richcmp(self.list(), other.list(), op)
</pre><blockquote class="citation">
<blockquote class="citation">
<p>
I think <code>(dual_)basis</code> should return a <code>Family</code> (or a <code>Sequence</code>, but this has a more limited feature set) to be consistent with other parts of Sage in <code>ModulesWithBasis</code>.
</p>
</blockquote>
<p>
Well, ok for returning a <code>Family</code>...
</p>
</blockquote>
<p>
Thank you. This also makes it so <code>self.basis().cardinality()</code> and <code>self.basis().keys()</code> works and helps make things uniform.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Why all the same definition of <code>__hash__</code>? You are not doing a new <code>__eq__</code>/<code>__richcmp__</code>, so there should not be a need to do this. Why not have this be in the ABC and override when you need to?
</p>
</blockquote>
<p>
It seems that you must have to redefine <code>__hash__</code> in each class even if the code does not change (otherwise I got an error). I don't know why.
</p>
</blockquote>
<p>
That is very strange. I would figure it would be sufficient for some ABC. I might have to look more closely into that.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
General question, how much speed do you think you need with these elements? It might be worthwhile to consider Cythonizing the elements.
</p>
</blockquote>
<p>
For now, I'm not that concerned with speed. But on the other hand, I'm aware that my code is rather slow (especially for iteration polynomial rings). I will probably (one day) consider Cythonizing derivations but, except if you strongly disagree, it will be for another ticket.
</p>
</blockquote>
<p>
Another ticket is fine. It is slightly easier to split the element class into a Cython file here than on a separate ticket, but only slightly. I am fine with whatever you decide.
</p>
TicketgitThu, 27 Sep 2018 13:20:51 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:33
https://trac.sagemath.org/ticket/25134#comment:33
<ul>
<li><strong>commit</strong>
changed from <em>c9deb7f95efb4d87907c27b738027be838578f23</em> to <em>369db6af5d5d939f10f7b567715753a86ba87963</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=369db6af5d5d939f10f7b567715753a86ba87963"><span class="icon"></span>369db6a</a></td><td><code>Address Travis' review</code>
</td></tr></table>
TicketcarusoThu, 27 Sep 2018 13:26:26 GMT
https://trac.sagemath.org/ticket/25134#comment:34
https://trac.sagemath.org/ticket/25134#comment:34
<p>
There is still a bug with pickling but it's not because of this ticket.
</p>
<p>
I've opened up a new ticket (<a class="closed ticket" href="https://trac.sagemath.org/ticket/26354" title="defect: Pickling morphisms is broken (closed: fixed)">#26354</a>) reporting the bug.
</p>
TicketcarusoThu, 27 Sep 2018 13:31:36 GMTdependencies set
https://trac.sagemath.org/ticket/25134#comment:35
https://trac.sagemath.org/ticket/25134#comment:35
<ul>
<li><strong>dependencies</strong>
set to <em>#26354</em>
</li>
</ul>
TicketgitThu, 27 Sep 2018 22:01:35 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:36
https://trac.sagemath.org/ticket/25134#comment:36
<ul>
<li><strong>commit</strong>
changed from <em>369db6af5d5d939f10f7b567715753a86ba87963</em> to <em>267f74db4e8a9dafa32dba059a74302a5b2c1522</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=94f6985f60c352044b4d99bf8fc15818c17c7281"><span class="icon"></span>94f6985</a></td><td><code>Set immutable in unpickling ring morphisms</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=c4fffe277a5df5d9ce3f4811379ef31cb297cb4f"><span class="icon"></span>c4fffe2</a></td><td><code>Merge branch 't/26354/pickling_morphisms_is_broken' into t/25134/derivation</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=267f74db4e8a9dafa32dba059a74302a5b2c1522"><span class="icon"></span>267f74d</a></td><td><code>Implement _richcmp_ for twisted derivations</code>
</td></tr></table>
TickettscrimThu, 27 Sep 2018 23:33:56 GMTcommit, branch changed
https://trac.sagemath.org/ticket/25134#comment:37
https://trac.sagemath.org/ticket/25134#comment:37
<ul>
<li><strong>commit</strong>
changed from <em>267f74db4e8a9dafa32dba059a74302a5b2c1522</em> to <em>f0878ebfc46ce776f011ec4d9b059be8bb05215c</em>
</li>
<li><strong>branch</strong>
changed from <em>u/caruso/derivation</em> to <em>u/tscrim/polynomial_derivations-25134</em>
</li>
</ul>
<p>
Thank you for all the changes. I made a few reviewer changes to fix the docbuild error, some broken doc links, bad formatting, and other small adjustments. I also did a bunch of PEP8 consistency changes.
</p>
<p>
If my changes are good with you, then positive review.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=f0878ebfc46ce776f011ec4d9b059be8bb05215c"><span class="icon"></span>f0878eb</a></td><td><code>Fixing some docstrings and some PEP8.</code>
</td></tr></table>
TicketcarusoFri, 28 Sep 2018 07:03:11 GMTbranch changed
https://trac.sagemath.org/ticket/25134#comment:38
https://trac.sagemath.org/ticket/25134#comment:38
<ul>
<li><strong>branch</strong>
changed from <em>u/tscrim/polynomial_derivations-25134</em> to <em>u/caruso/polynomial_derivations-25134</em>
</li>
</ul>
TicketcarusoFri, 28 Sep 2018 07:04:21 GMT
https://trac.sagemath.org/ticket/25134#comment:39
https://trac.sagemath.org/ticket/25134#comment:39
<p>
I've fixed a few typos in the doctest.
</p>
<p>
I can give a positive review now but maybe it's better to wait for <a class="closed ticket" href="https://trac.sagemath.org/ticket/26354" title="defect: Pickling morphisms is broken (closed: fixed)">#26354</a>. What's your opinion?
</p>
TicketgitFri, 28 Sep 2018 07:55:32 GMTcommit changed
https://trac.sagemath.org/ticket/25134#comment:40
https://trac.sagemath.org/ticket/25134#comment:40
<ul>
<li><strong>commit</strong>
changed from <em>f0878ebfc46ce776f011ec4d9b059be8bb05215c</em> to <em>dbe85c5ad7d56bf63c9d26b48669f02aa6b71ce7</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=dbe85c5ad7d56bf63c9d26b48669f02aa6b71ce7"><span class="icon"></span>dbe85c5</a></td><td><code>Typos</code>
</td></tr></table>
TickettscrimFri, 28 Sep 2018 13:40:27 GMTstatus changed
https://trac.sagemath.org/ticket/25134#comment:41
https://trac.sagemath.org/ticket/25134#comment:41
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
It's a positive review, but it won't get merged until the dependency is merged.
</p>
TicketgitMon, 01 Oct 2018 10:47:31 GMTstatus, commit changed
https://trac.sagemath.org/ticket/25134#comment:42
https://trac.sagemath.org/ticket/25134#comment:42
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>dbe85c5ad7d56bf63c9d26b48669f02aa6b71ce7</em> to <em>c8fee99e5ac2c4148b885cb33367d4b64da7822c</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=dee878eed8fea9505e8c2ecfb907ebf6cbb78fb1"><span class="icon"></span>dee878e</a></td><td><code>Revert "Set immutable in unpickling ring morphisms"</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=e2931b6b109cd7fb492945c93e90be7cd68a30bc"><span class="icon"></span>e2931b6</a></td><td><code>Fix pickling for PolynomialSequence_generic</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=1ea91f7b6254f8791b4f0b488e32c002af7e99a0"><span class="icon"></span>1ea91f7</a></td><td><code>Add a doctest</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=c8fee99e5ac2c4148b885cb33367d4b64da7822c"><span class="icon"></span>c8fee99</a></td><td><code>Merge branch 't/26354/pickling_morphisms_is_broken' into t/25134/polynomial_derivations-25134</code>
</td></tr></table>
TicketcarusoMon, 01 Oct 2018 10:48:55 GMTstatus changed
https://trac.sagemath.org/ticket/25134#comment:43
https://trac.sagemath.org/ticket/25134#comment:43
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
I just merged with <a class="closed ticket" href="https://trac.sagemath.org/ticket/26354" title="defect: Pickling morphisms is broken (closed: fixed)">#26354</a>. Actually, I'm not sure it was needed but it's probably safer like this.
</p>
TicketvbraunWed, 03 Oct 2018 21:56:26 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/25134#comment:44
https://trac.sagemath.org/ticket/25134#comment:44
<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>u/caruso/polynomial_derivations-25134</em> to <em>c8fee99e5ac2c4148b885cb33367d4b64da7822c</em>
</li>
</ul>
Ticket