#15299: Incorrect results for analytic Sha due to low precision
-------------------------------------------------+-------------------------
Reporter: jdemeyer | Owner:
Type: defect | Status:
Priority: major | positive_review
Component: elliptic curves | Milestone: sage-
Keywords: | pending
Authors: Jeroen Demeyer | Resolution:
Report Upstream: Fixed upstream, but not in a | Merged in:
stable release. | Reviewers: Peter
Branch: | Bruin
Dependencies: #15337 | Work issues:
| Commit:
| Stopgaps:
-------------------------------------------------+-------------------------
Changes (by jdemeyer):
* upstream: N/A => Fixed upstream, but not in a stable release.
Old description:
> See [https://groups.google.com/forum/#!topic/sage-support/rYQ4rWyncG4]
> {{{
> 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)
> }}}
>
> This seems to be due to inappropriate use of Python floats instead of
> more precise real numbers. After the patch:
> {{{
> 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)
> }}}
New description:
See [https://groups.google.com/forum/#!topic/sage-support/rYQ4rWyncG4]
{{{
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)
}}}
This seems to be due to inappropriate use of Python floats instead of more
precise real numbers. After the patch:
{{{
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)
}}}
While working on this, we found an upstream PARI bug: the precision for
`exponential_integal_1()` was not as good as it could be.
--
Comment:
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...
--
Ticket URL: <http://trac.sagemath.org/ticket/15299#comment:27>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
