Sage: Ticket #15299: Incorrect results for analytic Sha due to low precision
https://trac.sagemath.org/ticket/15299
<p>
See <a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-support/rYQ4rWyncG4"><span class="icon"></span>https://groups.google.com/forum/#!topic/sage-support/rYQ4rWyncG4</a>
</p>
<pre class="wiki">sage: E = EllipticCurve(QQ,[0, 0, 1, -79, 342]); E.sha().an(),E.sha().an_numerical()
(0, 1.00000000000000)
sage: E.lseries().deriv_at1(100*sqrt(E.conductor()) + 10) # L1, error_bound
(1.94655218772191e-15, 1.82478252135394e-270)
</pre><p>
This seems to be due to inappropriate use of Python floats instead of more precise real numbers. After the patch:
</p>
<pre class="wiki">sage: E = EllipticCurve(QQ,[0, 0, 1, -79, 342]); E.sha().an(),E.sha().an_numerical()
(1.00000000000000, 1.00000000000000)
sage: E.lseries().deriv_at1(100*sqrt(E.conductor()) + 10) # L1, error_bound
(-4.32787398660869448751904675450772492666840247314688171540527473331725818170217268435223462033366791557160872926179439894639315476270837428785657638252738603056742447337636326343956370276624493916496382120766160023620812331280787034239648552009947468067829864968026720015203778821069593806584e-277,
1.82478252137476307223140369768561190028055347258560054363485475966241792307587640145132294203994875344783110100551912347495775160520204557245032474939095251969168953786545612090565728262067746413119194690260652692254781091147749697957445424152473292233020112755190503925812425294821095313979e-270)
</pre><p>
While working on this, we found an upstream PARI bug: the precision for <code>exponential_integal_1()</code> was not as good as it could be.
</p>
<p>
Apply: <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/15299/15299_lseries_prec.patch" title="Attachment '15299_lseries_prec.patch' in Ticket #15299">15299_lseries_prec.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/15299/15299_lseries_prec.patch" title="Download"></a>, <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/15299/15299_reviewer.patch" title="Attachment '15299_reviewer.patch' in Ticket #15299">15299_reviewer.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/15299/15299_reviewer.patch" title="Download"></a>
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/15299
Trac 1.2Jeroen DemeyerWed, 16 Oct 2013 21:07:31 GMTdescription changed
https://trac.sagemath.org/ticket/15299#comment:1
https://trac.sagemath.org/ticket/15299#comment:1
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15299?action=diff&version=1">diff</a>)
</li>
</ul>
TicketWilliam SteinWed, 16 Oct 2013 21:11:27 GMT
https://trac.sagemath.org/ticket/15299#comment:2
https://trac.sagemath.org/ticket/15299#comment:2
<p>
It gets worse!
</p>
<pre class="wiki">sage: E = EllipticCurve('11a')
sage: E.lseries().deriv_at1()
0
sage: E.lseries().dokchitser().derivative(1)
0.308708533963172
</pre><p>
I.e., it is wrong for all curves of rank 0 too... (This isn't what we wrote the code for. Ugh.)
</p>
TicketJeroen DemeyerWed, 16 Oct 2013 22:20:17 GMT
https://trac.sagemath.org/ticket/15299#comment:3
https://trac.sagemath.org/ticket/15299#comment:3
<p>
So this is plain wrong then (I don't know enough mathematics to judge this):
</p>
<pre class="wiki"> if self.__E.root_number() == 1:
return 0
</pre>
TicketJeroen DemeyerWed, 16 Oct 2013 22:32:54 GMT
https://trac.sagemath.org/ticket/15299#comment:4
https://trac.sagemath.org/ticket/15299#comment:4
<p>
I don't know about <code>11a1</code>, but this at least fixes the original problem.
</p>
TicketJohn CremonaThu, 17 Oct 2013 08:52:52 GMT
https://trac.sagemath.org/ticket/15299#comment:5
https://trac.sagemath.org/ticket/15299#comment:5
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:3" title="Comment 3">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
So this is plain wrong then (I don't know enough mathematics to judge this):
</p>
<pre class="wiki"> if self.__E.root_number() == 1:
return 0
</pre></blockquote>
<p>
The root number is the sign of the functional equation so is +1 for even analytic rank and -1 for odd. This function computes the first derivative. *In practice* this is something one would only want to do if the 0'th derivative was already known to be 0, in which case the code you quote would be OK since if the value is 0 and the order is even then the order is at least 2 so the first derivative is exactly 0. But of course this function then lies in wait for the user who decides they want the first derivative's value even when the value is nonzero (as for 11a1). The trouble is that (1) Formulas for the r'th derivative which are implemented are *only* valid under the assumption that all previous derivatives are 0; and of course (2) proving the earlier derivatives are exactly 0 is usually impossible with current theory.
</p>
<p>
Where does that leave this deriv_at1 function? At the very least it should come with a huge warning about all this. And it really should return 0 when the root number is +1 unless the user has made an explicit assumption (assume_order_of_vanishing_is_positive=True, say) and otherwise raise a <a class="missing wiki">NotImplemented?</a> error (or attempt to prove that L(1)=0).
</p>
TicketJeroen DemeyerThu, 17 Oct 2013 19:16:34 GMTstatus changed
https://trac.sagemath.org/ticket/15299#comment:6
https://trac.sagemath.org/ticket/15299#comment:6
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketJeroen DemeyerThu, 17 Oct 2013 20:23:57 GMTdescription changed
https://trac.sagemath.org/ticket/15299#comment:7
https://trac.sagemath.org/ticket/15299#comment:7
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15299?action=diff&version=7">diff</a>)
</li>
</ul>
TicketJeroen DemeyerThu, 17 Oct 2013 21:39:06 GMTdescription changed
https://trac.sagemath.org/ticket/15299#comment:8
https://trac.sagemath.org/ticket/15299#comment:8
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15299?action=diff&version=8">diff</a>)
</li>
</ul>
TicketJohn CremonaFri, 18 Oct 2013 14:06:37 GMT
https://trac.sagemath.org/ticket/15299#comment:9
https://trac.sagemath.org/ticket/15299#comment:9
<p>
...review in progress...and all works fine, including docbuilding. the changes look good to the human eye (this one at least). Oops, forgot the --long when testing..... and it's still all good. Thanks, Jeroen!
</p>
TicketJeroen DemeyerSun, 20 Oct 2013 21:48:02 GMT
https://trac.sagemath.org/ticket/15299#comment:10
https://trac.sagemath.org/ticket/15299#comment:10
<p>
Corrected the error computation for <code>at1()</code>. I believe this is rigorous now:
</p>
<pre class="wiki"> for n in xrange(1,k+1):
term = (zpow * an[n])/n
zpow *= z
L += term
# 8n+1 is the relative error in half-ulps to compute term.
# For addition, multiplication, division, sqrt, this is
# bounded by the number of operations. exp(x) multiplies the
# relative error by abs(x) and adds 1 half-ulp. The relative
# error for -2*pi/sqrtN is 3 half-ulps. Assuming that
# 2*pi/sqrtN <= 2, the relative error for z is 7 half-ulps.
# This implies a relative error of 8n-1 half-ulps for zpow.
# Adding 2 for the computation of term gives:
error += term.ulp()*(8*n+1) + L.ulp()
</pre>
TicketJohn CremonaMon, 21 Oct 2013 08:43:22 GMT
https://trac.sagemath.org/ticket/15299#comment:11
https://trac.sagemath.org/ticket/15299#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:10" title="Comment 10">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Corrected the error computation for <code>at1()</code>. I believe this is rigorous now:
</p>
<pre class="wiki"> for n in xrange(1,k+1):
term = (zpow * an[n])/n
zpow *= z
L += term
# 8n+1 is the relative error in half-ulps to compute term.
# For addition, multiplication, division, sqrt, this is
# bounded by the number of operations. exp(x) multiplies the
# relative error by abs(x) and adds 1 half-ulp. The relative
# error for -2*pi/sqrtN is 3 half-ulps. Assuming that
# 2*pi/sqrtN <= 2, the relative error for z is 7 half-ulps.
# This implies a relative error of 8n-1 half-ulps for zpow.
# Adding 2 for the computation of term gives:
error += term.ulp()*(8*n+1) + L.ulp()
</pre></blockquote>
<p>
I can see where this is in the code -- can you say how it affects any doctest outputs? I am not a numerical analyst...
</p>
TicketJeroen DemeyerMon, 21 Oct 2013 09:52:53 GMT
https://trac.sagemath.org/ticket/15299#comment:12
https://trac.sagemath.org/ticket/15299#comment:12
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:11" title="Comment 11">cremona</a>:
</p>
<blockquote class="citation">
<p>
can you say how it affects any doctest outputs?
</p>
</blockquote>
<p>
I would only make the <code>error</code> results slightly larger than before. Perhaps more importantly, I believe the error computation is now rigorous, in the sense that one could <em>prove</em> that the actual error is bound by the <code>error</code> result.
</p>
TicketJeroen DemeyerMon, 28 Oct 2013 12:06:08 GMT
https://trac.sagemath.org/ticket/15299#comment:13
https://trac.sagemath.org/ticket/15299#comment:13
<p>
If you care less about speed, I could also write a version using interval arithmetic, which will be simpler but slower.
</p>
TicketJeroen DemeyerThu, 31 Oct 2013 08:14:57 GMT
https://trac.sagemath.org/ticket/15299#comment:14
https://trac.sagemath.org/ticket/15299#comment:14
<p>
Added tolerance to <code>E.lseries().twist_values(1, -12, -4)</code> doctest to account for doctest failure on ia64.
</p>
TicketJeroen DemeyerMon, 04 Nov 2013 07:24:31 GMT
https://trac.sagemath.org/ticket/15299#comment:15
https://trac.sagemath.org/ticket/15299#comment:15
<p>
Passes tests on the buildbots now.
</p>
TicketPeter BruinMon, 04 Nov 2013 17:30:32 GMT
https://trac.sagemath.org/ticket/15299#comment:16
https://trac.sagemath.org/ticket/15299#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:5" title="Comment 5">cremona</a>:
</p>
<blockquote class="citation">
<p>
Where does that leave this deriv_at1 function? At the very least it should come with a huge warning about all this. And it really should return 0 when the root number is +1 unless the user has made an explicit assumption (assume_order_of_vanishing_is_positive=True, say) and otherwise raise a <a class="missing wiki">NotImplemented?</a> error (or attempt to prove that L(1)=0).
</p>
</blockquote>
<p>
The <code>Lseries_ell</code> class has a method <code>L1_vanishes()</code>, written by William Stein. According to the documentation, it is provably correct if the Manin constant is <= 2 for the optimal quotient in the isogeny class. This method is used in some places, but not currently in <code>deriv_at1()</code>, where we might use it to check the assumption <em>L</em>(<em>E</em>, 1) = 0. If that is too slow, a <code>check=False</code> flag could be added.
</p>
TicketPeter BruinMon, 04 Nov 2013 17:32:58 GMT
https://trac.sagemath.org/ticket/15299#comment:17
https://trac.sagemath.org/ticket/15299#comment:17
<p>
Jeroen, do you have a particular reason for writing <code>QQ()</code> and <code>R()</code> instead of <code>QQ(0)</code> and <code>R(0)</code>? It saves one character, but is less readable.
</p>
TicketJeroen DemeyerMon, 04 Nov 2013 19:34:23 GMT
https://trac.sagemath.org/ticket/15299#comment:18
https://trac.sagemath.org/ticket/15299#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:17" title="Comment 17">pbruin</a>:
</p>
<blockquote class="citation">
<p>
Jeroen, do you have a particular reason for writing <code>QQ()</code> and <code>R()</code> instead of <code>QQ(0)</code> and <code>R(0)</code>? It saves one character, but is less readable.
</p>
</blockquote>
<p>
No reason, it's just a habit to think in term of default constructors (I guess this is my C++ background). I just benchmarked <code>QQ()</code>, <code>QQ(0)</code> and <code>QQ.zero()</code> and the latter is the fastest, so perhaps we should use that.
</p>
TicketJeroen DemeyerMon, 04 Nov 2013 20:23:16 GMT
https://trac.sagemath.org/ticket/15299#comment:19
https://trac.sagemath.org/ticket/15299#comment:19
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:16" title="Comment 16">pbruin</a>:
</p>
<blockquote class="citation">
<p>
The <code>Lseries_ell</code> class has a method <code>L1_vanishes()</code>, written by William Stein. According to the documentation, it is provably correct if the Manin constant is <= 2 for the optimal quotient in the isogeny class. This method is used in some places, but not currently in <code>deriv_at1()</code>, where we might use it to check the assumption <em>L</em>(<em>E</em>, 1) = 0. If that is too slow, a <code>check=False</code> flag could be added.
</p>
</blockquote>
<p>
Do you propose that this change should be made, or is it just an observation? Given that the function <code>deriv_at1()</code> is in practice only called when we know that <code>L(E,1) = 0</code>, I personally think the warning suffices.
</p>
TicketPeter BruinMon, 04 Nov 2013 21:12:54 GMT
https://trac.sagemath.org/ticket/15299#comment:20
https://trac.sagemath.org/ticket/15299#comment:20
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:19" title="Comment 19">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Do you propose that this change should be made, or is it just an observation? Given that the function <code>deriv_at1()</code> is in practice only called when we know that <code>L(E,1) = 0</code>, I personally think the warning suffices.
</p>
</blockquote>
<p>
I agree, it was more an observation that we could in principle use <code>L1_vanishes()</code> here than a proposal to actually do it.
</p>
<p>
There is a formula for the <em>r</em>-th derivative which is valid when all lower derivatives vanish. As far as I know, only for the 0-th derivative is there a known way to prove that it vanishes by a numerical computation. For parity reasons (the root number), this means that if the order of vanishing is 0, 1 or 2, then we can prove this. If the order of vanishing is 3, then in general we don't know how to prove that it is not 1.
</p>
<p>
This means that if and when the formula mentioned above is implemented, we won't be able to verify the condition "all lower derivatives are 0" when <em>r</em> is at least 3. Hence we should probably not insist on verifying it when <em>r</em> = 1.
</p>
TicketPeter BruinMon, 04 Nov 2013 22:34:01 GMT
https://trac.sagemath.org/ticket/15299#comment:21
https://trac.sagemath.org/ticket/15299#comment:21
<p>
Another question: is it necessary to compute the error bound to the same precision as the result, i.e. in <code>RealField(prec)</code>? It seems sufficient, and more efficient, to compute it in a lower-precision <code>RealField</code> or even just using Python floats.
</p>
TicketJohn CremonaTue, 05 Nov 2013 09:31:38 GMT
https://trac.sagemath.org/ticket/15299#comment:22
https://trac.sagemath.org/ticket/15299#comment:22
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:20" title="Comment 20">pbruin</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:19" title="Comment 19">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Do you propose that this change should be made, or is it just an observation? Given that the function <code>deriv_at1()</code> is in practice only called when we know that <code>L(E,1) = 0</code>, I personally think the warning suffices.
</p>
</blockquote>
<p>
I agree, it was more an observation that we could in principle use <code>L1_vanishes()</code> here than a proposal to actually do it.
</p>
<p>
There is a formula for the <em>r</em>-th derivative which is valid when all lower derivatives vanish. As far as I know, only for the 0-th derivative is there a known way to prove that it vanishes by a numerical computation. For parity reasons (the root number), this means that if the order of vanishing is 0, 1 or 2, then we can prove this. If the order of vanishing is 3, then in general we don't know how to prove that it is not 1.
</p>
</blockquote>
<p>
You can go one step further thanks to Gross-Zagier: if the parity is odd and L'(1) looks zero then you can prove it, since if in fact L'(1)!=0 then the curve would have rank 1, but you can disprove that by finding three (or oeven only 2) independent points. See by talk <a class="ext-link" href="http://homepages.warwick.ac.uk/staff/J.E.Cremona/papers/bsd50.pdf"><span class="icon"></span>http://homepages.warwick.ac.uk/staff/J.E.Cremona/papers/bsd50.pdf</a> if you want to read more!
</p>
<blockquote class="citation">
<p>
This means that if and when the formula mentioned above is implemented, we won't be able to verify the condition "all lower derivatives are 0" when <em>r</em> is at least 3. Hence we should probably not insist on verifying it when <em>r</em> = 1.
</p>
</blockquote>
TicketPeter BruinWed, 06 Nov 2013 12:18:39 GMT
https://trac.sagemath.org/ticket/15299#comment:23
https://trac.sagemath.org/ticket/15299#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:22" title="Comment 22">cremona</a>:
</p>
<blockquote class="citation">
<p>
You can go one step further thanks to Gross-Zagier: if the parity is odd and L'(1) looks zero then you can prove it, since if in fact L'(1)!=0 then the curve would have rank 1, but you can disprove that by finding three (or oeven only 2) independent points.
</p>
</blockquote>
<p>
That is true (in fact I seem to remember learning this from the talk you linked to). However, it does require you to search for points; there seems to be no "analytic" way of proving that L'(1) = 0 by computing it to finite precision, like the <code>L1_vanishes()</code> function.
</p>
TicketJeroen DemeyerFri, 08 Nov 2013 16:06:04 GMT
https://trac.sagemath.org/ticket/15299#comment:24
https://trac.sagemath.org/ticket/15299#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:21" title="Comment 21">pbruin</a>:
</p>
<blockquote class="citation">
<p>
Another question: is it necessary to compute the error bound to the same precision as the result, i.e. in <code>RealField(prec)</code>? It seems sufficient, and more efficient, to compute it in a lower-precision <code>RealField</code>
</p>
</blockquote>
<p>
Done. Needs <a class="closed ticket" href="https://trac.sagemath.org/ticket/15337" title="#15337: enhancement: Speed up ulp() method of real_mpfr.pyx (closed: fixed)">#15337</a>.
</p>
<blockquote class="citation">
<p>
or even just using Python floats.
</p>
</blockquote>
<p>
Not a good idea, as these have limited range and it's a lot harder (maybe even impossible) to control the rounding. One doctest has an error of 2.74997188336901e-449, which would be rounded to 0.0 as Python <code>float</code>.
</p>
TicketPeter BruinFri, 08 Nov 2013 23:46:41 GMTstatus changed; reviewer, dependencies set
https://trac.sagemath.org/ticket/15299#comment:25
https://trac.sagemath.org/ticket/15299#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Peter Bruin</em>
</li>
<li><strong>dependencies</strong>
set to <em>#15337</em>
</li>
</ul>
<p>
This looks very good now. The error analysis appears to be completely rigorous for <code>at1()</code> and almost completely rigorous for <code>deriv_at1()</code>, the only source of non-rigorousness being due to the unknown error in the exponential integral function <code>eint1()</code> from PARI. This ticket is not the place to try to fix this, though.
</p>
<p>
Are the PARI developers aware of this precision issue? Should it be regarded it as a bug, or does PARI not strive for proven error bounds for functions such as <code>eint1()</code>?
</p>
TicketJeroen DemeyerSat, 09 Nov 2013 14:26:56 GMTmilestone changed
https://trac.sagemath.org/ticket/15299#comment:26
https://trac.sagemath.org/ticket/15299#comment:26
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.13</em> to <em>sage-pending</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/15299#comment:25" title="Comment 25">pbruin</a>:
</p>
<blockquote class="citation">
<p>
Are the PARI developers aware of this precision issue?
</p>
</blockquote>
<p>
No idea. I might report it.
</p>
<blockquote class="citation">
<p>
does PARI not strive for proven error bounds for functions such as <code>eint1()</code>?
</p>
</blockquote>
<p>
I don't think PARI does. However, the errors are quite large (over 30 bits can be wrong), so perhaps that's a bug indeed.
</p>
TicketJeroen DemeyerSat, 09 Nov 2013 23:09:47 GMTdescription, upstream changed
https://trac.sagemath.org/ticket/15299#comment:27
https://trac.sagemath.org/ticket/15299#comment:27
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15299?action=diff&version=27">diff</a>)
</li>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Fixed upstream, but not in a stable release.</em>
</li>
</ul>
<p>
Reported the precision issue, they fixed it. There is supposed to be an absolute error bound (not relative), but I don't know what the bound is...
</p>
TicketJeroen DemeyerTue, 12 Nov 2013 23:47:36 GMTdependencies changed
https://trac.sagemath.org/ticket/15299#comment:28
https://trac.sagemath.org/ticket/15299#comment:28
<ul>
<li><strong>dependencies</strong>
changed from <em>#15337</em> to <em>#15337, #15402</em>
</li>
</ul>
<p>
Moved part of the patch to <a class="closed ticket" href="https://trac.sagemath.org/ticket/15402" title="#15402: enhancement: PARI: add patch for exponential_integral_1() precision (closed: fixed)">#15402</a>.
</p>
TicketJeroen DemeyerWed, 13 Nov 2013 16:42:22 GMTattachment set
https://trac.sagemath.org/ticket/15299
https://trac.sagemath.org/ticket/15299
<ul>
<li><strong>attachment</strong>
set to <em>15299_lseries_prec.patch</em>
</li>
</ul>
TicketJeroen DemeyerWed, 13 Nov 2013 16:44:43 GMTstatus changed
https://trac.sagemath.org/ticket/15299#comment:29
https://trac.sagemath.org/ticket/15299#comment:29
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_review</em>
</li>
</ul>
<p>
Changed error bounds because of <a class="closed ticket" href="https://trac.sagemath.org/ticket/15402" title="#15402: enhancement: PARI: add patch for exponential_integral_1() precision (closed: fixed)">#15402</a>, needs review.
</p>
TicketPeter BruinTue, 19 Nov 2013 18:20:04 GMTstatus changed
https://trac.sagemath.org/ticket/15299#comment:30
https://trac.sagemath.org/ticket/15299#comment:30
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Looks even better than before, the precision is now much better under control thanks to <a class="closed ticket" href="https://trac.sagemath.org/ticket/15402" title="#15402: enhancement: PARI: add patch for exponential_integral_1() precision (closed: fixed)">#15402</a>, and the remaining "arbitrary" precision increase is clearly motivated.
</p>
<p>
As in <a class="closed ticket" href="https://trac.sagemath.org/ticket/15402" title="#15402: enhancement: PARI: add patch for exponential_integral_1() precision (closed: fixed)">#15402</a>, just a trivial review patch to refer to a section instead of a page number in Cohen's book.
</p>
TicketPeter BruinTue, 19 Nov 2013 18:21:41 GMTattachment set
https://trac.sagemath.org/ticket/15299
https://trac.sagemath.org/ticket/15299
<ul>
<li><strong>attachment</strong>
set to <em>15299_reviewer.patch</em>
</li>
</ul>
<p>
replace page number by section number in Cohen reference
</p>
TicketPeter BruinTue, 19 Nov 2013 18:22:41 GMTdescription changed
https://trac.sagemath.org/ticket/15299#comment:31
https://trac.sagemath.org/ticket/15299#comment:31
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/15299?action=diff&version=31">diff</a>)
</li>
</ul>
TicketJeroen DemeyerFri, 22 Nov 2013 15:50:22 GMTmilestone changed
https://trac.sagemath.org/ticket/15299#comment:32
https://trac.sagemath.org/ticket/15299#comment:32
<ul>
<li><strong>milestone</strong>
changed from <em>sage-pending</em> to <em>sage-5.13</em>
</li>
</ul>
TicketJeroen DemeyerSun, 24 Nov 2013 17:26:13 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/15299#comment:33
https://trac.sagemath.org/ticket/15299#comment:33
<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>merged</strong>
set to <em>sage-5.13.beta4</em>
</li>
</ul>
Ticket