Sage: Ticket #12879: TestSuite failures for HeckeModule Homsets
https://trac.sagemath.org/ticket/12879
<p>
Adding a Testsuite run in <a class="closed ticket" href="https://trac.sagemath.org/ticket/12876" title="enhancement: Fix element and parent classes of Hom categories to be abstract, and ... (closed: fixed)">#12876</a> in the documentation of
sage.categories.hecke_modules.<a class="missing wiki">HeckeModules?</a>.<a class="missing wiki">ParentMethods?</a>._Hom_
revealed the following bug:
</p>
<pre class="wiki">sage: M = ModularForms(Gamma0(7), 4)
sage: H = Hom(M); H
sage: H.zero()
Traceback (most recent call last):
File "<ipython console>", line 1, in <module>
File "cachefunc.pyx", line 1397, in sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ (sage/misc/cachefunc.c:7026)
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/categories/modules.py", line 221, in zero
From: Free module generated by {1, 2, 3} over Integer Ring
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/modular/hecke/homspace.py", line 111, in __call__
return morphism.HeckeModuleMorphism_matrix(self, A, name)
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/modular/hecke/morphism.py", line 116, in __init__
MatrixMorphism.__init__(self, parent, A)
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/modules/matrix_morphism.py", line 1191, in __init__
parent.codomain().rank())(A)
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 543, in __call__
return self.matrix(entries, copy=copy, coerce=coerce, rows=rows)
File "/opt/sage-5.0.beta11/local/lib/python2.7/site-packages/sage/matrix/matrix_space.py", line 1372, in matrix
return self.__matrix_class(self, entries=x, copy=copy, coerce=coerce)
File "matrix_rational_dense.pyx", line 205, in sage.matrix.matrix_rational_dense.Matrix_rational_dense.__init__ (sage/matrix/matrix_rational_dense.c:5788)
TypeError: entries must be coercible to a list or integer
</pre><p>
<code>TestSuite(H).run()</code> also fails for "_test_elements".
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12879
Trac 1.1.6SimonKingWed, 29 Aug 2012 07:40:56 GMT
https://trac.sagemath.org/ticket/12879#comment:1
https://trac.sagemath.org/ticket/12879#comment:1
<p>
Nicolas suggested to me to move this from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12876" title="enhancement: Fix element and parent classes of Hom categories to be abstract, and ... (closed: fixed)">#12876</a> to here. I found the following steps needed:
</p>
<ul><li>Make <code>HeckeModule_generic</code> inherit from <code>UniqueRepresentation</code>. I guess it was for a reason that William did not always want modular forms being cached (there <em>is</em> a cache, but it isn't always used). Since nowadays the cache has weak keys, it shouldn't be so bad. I'll ask on sage-nt.
</li><li>Provide the Hecke homsets with a <code>__reduce__</code> method, so that (after the Hecke modules being unique) the homsets are identical.
</li><li>Provide the Hecke homsets with an <code>Element</code> attribute, and let the constructors return instances of the <code>element_class</code>. Note that there is only <em>one</em> type of morphisms being returned, hence, having a default element class absolutely makes sense.
</li><li>It was impossible to override the custom <code>__call__</code> method of Hecke homsets by a proper <code>_element_construtor_</code>, since there is yet another custon <code>__call__</code> method up in the class hierarchy.
</li><li>Provide the Hecke homsets with a <code>zero()</code> method - the default one wouldn't work.
</li><li>Provide the Hecke homsets with an <code>_an_element_</code> method. The idea is: Domain and codomain have a known dimension, and the morphisms are given by matrices anyway. Hence, I construct the corresponding matrix space (which I made a lazy attribute to the Hecke homsets), take <code>an_element</code> from the matrix space, and return the corresponding morphism.
</li></ul><p>
With that approach, I get
</p>
<pre class="wiki"> sage -t -force_lib devel/sage/sage/modular/modsym/ambient.py # 1 doctests failed
sage -t -force_lib devel/sage/sage/modular/abvar/homspace.py # 1 doctests failed
sage -t -force_lib devel/sage/sage/modular/modform/constructor.py # 3 doctests failed
sage -t -force_lib devel/sage/sage/modular/quatalg/brandt.py # 3 doctests failed
sage -t -force_lib devel/sage/sage/modular/hecke/ambient_module.py # 2 doctests failed
sage -t -force_lib devel/sage/sage/modular/modsym/modsym.py # 2 doctests failed
sage -t -force_lib devel/sage/sage/modular/abvar/homology.py # 9 doctests failed
sage -t -force_lib devel/sage/sage/modular/modform/hecke_operator_on_qexp.py # 2 doctests failed
</pre><p>
which isn't so bad, because most of them fail due to new class names from the category framework.
</p>
<p>
Suggestion: I provide a small reviewer patch at <a class="closed ticket" href="https://trac.sagemath.org/ticket/12876" title="enhancement: Fix element and parent classes of Hom categories to be abstract, and ... (closed: fixed)">#12876</a> making the <code>TestSuite</code> skip more tests, and then a proper solution will be dealt with here.
</p>
TicketSimonKingWed, 29 Aug 2012 07:43:08 GMT
https://trac.sagemath.org/ticket/12879#comment:2
https://trac.sagemath.org/ticket/12879#comment:2
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12879#comment:1" title="Comment 1">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
which isn't so bad, because most of them fail due to new class names from the category framework.
</p>
</blockquote>
<p>
Sorry, that was wrong. More nasty errors happen as well.
</p>
TicketSimonKingWed, 29 Aug 2012 12:30:30 GMT
https://trac.sagemath.org/ticket/12879#comment:3
https://trac.sagemath.org/ticket/12879#comment:3
<p>
Here is one particularly nasty thing. I stored some objects involved in errors. Reloading them, I find the following in a patched version (as suggested above):
</p>
<pre class="wiki">sage: A = load("/home/king/SAGE/work/categories/modformA")
sage: B = load("/home/king/SAGE/work/categories/modformB")
sage: A
Modular Symbols space of dimension 3 and level 5, weight 7, character [i], sign 1, over Number Field in c with defining polynomial x^2 - 402*i over its base field
sage: B
Modular Symbols space of dimension 3 and level 5, weight 7, character [i], sign 1, over Number Field in i with defining polynomial x^2 + 1
sage: A.boundary_space().dimension()
0
sage: K.<i> = QuadraticField(-1)
sage: x = polygen(K); L.<c> = K.extension(x^2 - 402*i)
sage: chi = DirichletGroup(5, K).gen(0)
sage: N = Newforms(chi, 7, base_ring = L)
sage: Newforms(chi, 7, names='a')
Traceback (most recent call last):
...
TypeError: Unable to coerce x (=[-1]
[-1]
[-1]) to a morphism in Set of Morphisms from Modular Symbols space of dimension 3 and level 5, weight 7, character [i], sign 1, over Number Field in i with defining polynomial x^2 + 1 to Boundary Modular Symbols space of level 5, weight 7, character [i] and dimension 1 over Number Field in c with defining polynomial x^2 - 402*i over its base field in Category of commutative additive groups
sage: A.boundary_space().dimension()
1
</pre><p>
Hence, <code>A.boundary_space()</code> used to be of dimension zero, but during the computation, it is turned into dimension one!
</p>
<p>
That does not happen without the patch:
</p>
<pre class="wiki">sage: A = load("/home/king/SAGE/work/categories/modformA")
sage: B = load("/home/king/SAGE/work/categories/modformB")
sage: A.boundary_space().dimension()
0
sage: K.<i> = QuadraticField(-1)
sage: x = polygen(K); L.<c> = K.extension(x^2 - 402*i)
sage: chi = DirichletGroup(5, K).gen(0)
sage: N = Newforms(chi, 7, base_ring = L)
sage: Newforms(chi, 7, names='a')
[q + a0*q^2 + (i*a0 - 5*i + 5)*q^3 + ((-5*i - 5)*a0 + 24*i)*q^4 + ((10*i - 5)*a0 - 40*i - 55)*q^5 + O(q^6)]
sage: A.boundary_space().dimension()
0
</pre><p>
Further digging reveals: <code>A.boundary_space().dimension()</code> is indeed <em>not</em> constant! It relies on a list of known generators, that may grow. But with my patch, the homset assumes that the dimensions are constant. Bad me.
</p>
TicketSimonKingWed, 29 Aug 2012 12:34:19 GMT
https://trac.sagemath.org/ticket/12879#comment:4
https://trac.sagemath.org/ticket/12879#comment:4
<p>
No, that didn't help.
</p>
TicketnthieryWed, 29 Aug 2012 12:54:07 GMT
https://trac.sagemath.org/ticket/12879#comment:5
https://trac.sagemath.org/ticket/12879#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12879#comment:4" title="Comment 4">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
No, that didn't help.
</p>
</blockquote>
<p>
Bah, unless you personnaly need this ticket to be fixed, you can just leave it to the number theory people. That's their problem :-)
</p>
<p>
+1 on the short reviewer patch on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12876" title="enhancement: Fix element and parent classes of Hom categories to be abstract, and ... (closed: fixed)">#12876</a>
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/12879#comment:6
https://trac.sagemath.org/ticket/12879#comment:6
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/12879#comment:7
https://trac.sagemath.org/ticket/12879#comment:7
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/12879#comment:8
https://trac.sagemath.org/ticket/12879#comment:8
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
Ticketvbraun_spamSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/12879#comment:9
https://trac.sagemath.org/ticket/12879#comment:9
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketchapotonThu, 27 Jul 2017 08:56:05 GMTstatus, milestone changed; commit, branch, author set
https://trac.sagemath.org/ticket/12879#comment:10
https://trac.sagemath.org/ticket/12879#comment:10
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
set to <em>578b8144d44d00316b107eafd915c60ebecb604e</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-8.1</em>
</li>
<li><strong>branch</strong>
set to <em>u/chapoton/12879</em>
</li>
<li><strong>author</strong>
set to <em>Frédéric Chapoton</em>
</li>
</ul>
<p>
Here is a try. Not perfect, but better than right now.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=578b8144d44d00316b107eafd915c60ebecb604e"><span class="icon"></span>578b814</a></td><td><code>trac 12879 some care for Hecke modules homsets</code>
</td></tr></table>
TicketchapotonThu, 27 Jul 2017 17:04:17 GMTcc set
https://trac.sagemath.org/ticket/12879#comment:11
https://trac.sagemath.org/ticket/12879#comment:11
<ul>
<li><strong>cc</strong>
<em>tscrim</em> added
</li>
</ul>
<p>
bot is morally green, please review
</p>
TickettscrimFri, 28 Jul 2017 17:00:31 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/12879#comment:12
https://trac.sagemath.org/ticket/12879#comment:12
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Travis Scrimshaw</em>
</li>
</ul>
<p>
LGTM. At least there is nothing in the documentation that seems to put a restriction on what the matrices could be.
</p>
TicketchapotonFri, 28 Jul 2017 18:25:04 GMT
https://trac.sagemath.org/ticket/12879#comment:13
https://trac.sagemath.org/ticket/12879#comment:13
<p>
Oh, I did not think about that. Indeed, these Hecke modules are modules, so there are some operators that should act in a compatible way on both domain and codomain. Maybe we should not implement this "naive" version of an_element, which is probably not correct.
</p>
TickettscrimSat, 29 Jul 2017 06:41:56 GMT
https://trac.sagemath.org/ticket/12879#comment:14
https://trac.sagemath.org/ticket/12879#comment:14
<p>
Well, there is no real documentation or checks in the code on this AFAICS. So as far as it is specified, any matrix will work. Perhaps also cc some number theory people to get their opinion?
</p>
TicketchapotonSat, 29 Jul 2017 06:45:22 GMTcc changed
https://trac.sagemath.org/ticket/12879#comment:15
https://trac.sagemath.org/ticket/12879#comment:15
<ul>
<li><strong>cc</strong>
<em>mderickx</em> <em>cremona</em> <em>davidloeffler</em> <em>jonhanke</em> added
</li>
</ul>
<p>
To specialists of modular forms and symbols, do you agree with the proposed implementation of "an_element" for the space of Hecke module morphisms ? In short, we just take a random matrix, and declare that it is a morphism, which seems dubious.
</p>
TicketmderickxSat, 29 Jul 2017 09:38:01 GMT
https://trac.sagemath.org/ticket/12879#comment:16
https://trac.sagemath.org/ticket/12879#comment:16
<p>
No, since it does not take into account that Hecke module are modules over some Hecke algebra. So indeed as you say earlier, morphisms should commute with the action of the Hecke operators on both sides. I think creating a valid nonzero element (if it exists, which is very often not the case) is something that is not trivial to implement. So I would maybe always just return the zero morphism. If domain and codomain are equal you could do something like <code>_.hecke_operator(2)</code> if you want a more typical element.
</p>
TicketchapotonSat, 29 Jul 2017 09:40:41 GMTstatus changed
https://trac.sagemath.org/ticket/12879#comment:17
https://trac.sagemath.org/ticket/12879#comment:17
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
ok, thanks
</p>
TicketgitSat, 29 Jul 2017 09:53:29 GMTcommit changed
https://trac.sagemath.org/ticket/12879#comment:18
https://trac.sagemath.org/ticket/12879#comment:18
<ul>
<li><strong>commit</strong>
changed from <em>578b8144d44d00316b107eafd915c60ebecb604e</em> to <em>dc917d4e81a9f7daf8560748c0747371440d75d8</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=dc917d4e81a9f7daf8560748c0747371440d75d8"><span class="icon"></span>dc917d4</a></td><td><code>trac 12879 implement a correct element</code>
</td></tr></table>
TicketchapotonSat, 29 Jul 2017 09:53:44 GMTstatus changed
https://trac.sagemath.org/ticket/12879#comment:19
https://trac.sagemath.org/ticket/12879#comment:19
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
done, please 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=dc917d4e81a9f7daf8560748c0747371440d75d8"><span class="icon"></span>dc917d4</a></td><td><code>trac 12879 implement a correct element</code>
</td></tr></table>
TicketmderickxSat, 29 Jul 2017 09:58:18 GMT
https://trac.sagemath.org/ticket/12879#comment:20
https://trac.sagemath.org/ticket/12879#comment:20
<p>
I also looked at the code in <code>__call__</code>, and the part that handles the case that A is an element of the basing only makes sense if the domain and codomain are actually the same space! If A is in the base ring but the domain and the codomain are unequal we should throw an Error.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=dc917d4e81a9f7daf8560748c0747371440d75d8"><span class="icon"></span>dc917d4</a></td><td><code>trac 12879 implement a correct element</code>
</td></tr></table>
TicketchapotonSat, 29 Jul 2017 10:18:07 GMT
https://trac.sagemath.org/ticket/12879#comment:21
https://trac.sagemath.org/ticket/12879#comment:21
<p>
The call of identity matrix will raise an error if the dimensions are not the same. Do you want an explicit check that domain == codomain ?
</p>
TicketgitSat, 29 Jul 2017 11:22:19 GMTcommit changed
https://trac.sagemath.org/ticket/12879#comment:22
https://trac.sagemath.org/ticket/12879#comment:22
<ul>
<li><strong>commit</strong>
changed from <em>dc917d4e81a9f7daf8560748c0747371440d75d8</em> to <em>1ea2824e6813a8f2bcaaae332537681126aded03</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=1ea2824e6813a8f2bcaaae332537681126aded03"><span class="icon"></span>1ea2824</a></td><td><code>trac 12879 stronger check for scalar elements</code>
</td></tr></table>
TicketvbraunSat, 29 Jul 2017 19:26:37 GMTmilestone changed
https://trac.sagemath.org/ticket/12879#comment:23
https://trac.sagemath.org/ticket/12879#comment:23
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.1</em> to <em>sage-8.2</em>
</li>
</ul>
TickettscrimSun, 30 Jul 2017 17:05:07 GMT
https://trac.sagemath.org/ticket/12879#comment:24
https://trac.sagemath.org/ticket/12879#comment:24
<p>
@vbraun Why the bump to 8.2?
</p>
TicketmderickxSun, 13 Aug 2017 21:52:57 GMT
https://trac.sagemath.org/ticket/12879#comment:25
https://trac.sagemath.org/ticket/12879#comment:25
<p>
Hi Sorry for not reacting earlier. I see that you added the explicit check for <code>domain == codomain</code> which is good! It is possible to construct hecke modules which have noting to do with each other that still have the same rank. And then asking for the identity matrix makes no sense, since it is a linear map that sends whichever basis we computed for the first space to a basis we computed for the second space, and since the basis are quite random so is the map. In particular it will rarely be a hecke module morphism.
</p>
TicketmderickxSun, 13 Aug 2017 21:54:48 GMT
https://trac.sagemath.org/ticket/12879#comment:26
https://trac.sagemath.org/ticket/12879#comment:26
<blockquote>
<p>
I've looked at the code and I can give a positive review on the mathematical content of this ticket. I have no Idea what all the <code>TestSuite</code> stuff is about. So is there someone else who can say that that part makes sense?
</p>
</blockquote>
TickettscrimMon, 14 Aug 2017 01:14:36 GMT
https://trac.sagemath.org/ticket/12879#comment:27
https://trac.sagemath.org/ticket/12879#comment:27
<p>
@mderickx <code>TestSuite</code> runs a bunch of "standard" tests on the object (i.e., all of the <code>_test_*</code> methods of an object) as a consistency check. Also, if you add your (real) name to the reviewers.
</p>
<p>
@chapoton I believe we are now claiming it passes the <code>TestSuite</code>, so I think we should explicitly add that as a doctest.
</p>
TicketchapotonSun, 20 Aug 2017 06:48:57 GMT
https://trac.sagemath.org/ticket/12879#comment:28
https://trac.sagemath.org/ticket/12879#comment:28
<p>
no, the <a class="missing wiki">TestSuite?</a> still does not pass:
</p>
<pre class="wiki"> The following tests failed: _test_category
Failure in _test_elements
The following tests failed: _test_elements
</pre>
TicketmderickxSun, 20 Aug 2017 12:55:35 GMT
https://trac.sagemath.org/ticket/12879#comment:29
https://trac.sagemath.org/ticket/12879#comment:29
<p>
Is it possible to get more verbose output?
</p>
TicketchapotonSun, 20 Aug 2017 13:13:43 GMT
https://trac.sagemath.org/ticket/12879#comment:30
https://trac.sagemath.org/ticket/12879#comment:30
<p>
oh, well, this says
</p>
<pre class="wiki"> Running the test suite of self.an_element()
running ._test_category() . . . fail
Traceback (most recent call last):
File "/home/chapoton/sage/local/lib/python2.7/site-packages/sage/misc/sage_unittest.py", line 293, in run
test_method(tester = tester)
File "sage/structure/element.pyx", line 687, in sage.structure.element.Element._test_category (/home/chapoton/sage/src/build/cythonized/sage/structure/element.c:6380)
tester.assert_(isinstance(self, self.parent().category().element_class))
File "/home/chapoton/sage/local/lib/python2.7/unittest/case.py", line 422, in assertTrue
raise self.failureException(msg)
AssertionError: False is not true
</pre>
TickettscrimSun, 20 Aug 2017 16:40:53 GMT
https://trac.sagemath.org/ticket/12879#comment:31
https://trac.sagemath.org/ticket/12879#comment:31
<p>
That is a common issue for Homsets because of it creating elements that are not specifically an instance of its unique <code>Element</code> class. Currently, we don't have the infastructure to really work around this.
</p>
<p>
Could we add a <code>TestSuite</code> that skips the <code>_test_elements</code> (this is done for other Homsets too)?
</p>
TicketgitSun, 20 Aug 2017 17:49:49 GMTcommit changed
https://trac.sagemath.org/ticket/12879#comment:32
https://trac.sagemath.org/ticket/12879#comment:32
<ul>
<li><strong>commit</strong>
changed from <em>1ea2824e6813a8f2bcaaae332537681126aded03</em> to <em>761ac1d2b925153462e3529a374abedb8a8ccb07</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=e7132eea7f646e36917251a6f8233aac10cfcfde"><span class="icon"></span>e7132ee</a></td><td><code>Merge branch 'u/chapoton/12879' in 8.1.b2</code>
</td></tr><tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit/?id=761ac1d2b925153462e3529a374abedb8a8ccb07"><span class="icon"></span>761ac1d</a></td><td><code>trac 12879 adding TesTsuite</code>
</td></tr></table>
TicketchapotonSun, 20 Aug 2017 17:50:15 GMT
https://trac.sagemath.org/ticket/12879#comment:33
https://trac.sagemath.org/ticket/12879#comment:33
<p>
done
</p>
TickettscrimSun, 20 Aug 2017 18:10:09 GMTstatus, reviewer, milestone changed
https://trac.sagemath.org/ticket/12879#comment:34
https://trac.sagemath.org/ticket/12879#comment:34
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Travis Scrimshaw</em> to <em>Travis Scrimshaw, Maarten Derickx</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-8.2</em> to <em>sage-8.1</em>
</li>
</ul>
<p>
Thank you.
</p>
TicketvbraunSat, 26 Aug 2017 09:58:09 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/12879#comment:35
https://trac.sagemath.org/ticket/12879#comment:35
<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/chapoton/12879</em> to <em>761ac1d2b925153462e3529a374abedb8a8ccb07</em>
</li>
</ul>
Ticket