#4214: elliptic_logarithm gives inaccurate answers
------------------------+---------------------------------------------------
Reporter: AlexGhitza | Owner: tbd
Type: defect | Status: new
Priority: major | Milestone: sage-3.1.3
Component: algebra | Keywords:
------------------------+---------------------------------------------------
It seems that our implementation of {{{elliptic_logarithm}}} performs much
worse than Pari's {{{ellpointtoz}}}. This is from an actual doctest in
{{{ell_point.py}}}:
{{{
sage: E = EllipticCurve([1, 0, 1, -85357462, 303528987048]) #18074g1
sage: P = E([4458713781401/835903744, -64466909836503771/24167649046528,
1])
sage: P.elliptic_logarithm(precision=54)
NaN
sage: P.elliptic_logarithm(precision=55)
0.2735052671206336
sage: P.elliptic_logarithm() # 100 bits
0.27656204014107100870070982517
}}}
Note that, while we ask for a precision of 55 bits (about 16 decimal
digits), we seem to only get 2 accurate digits! Compare this with the
following {{{gp}}} session:
{{{
? \p 16
realprecision = 19 significant digits (16 digits displayed)
? e = ellinit([1, 0, 1, -85357462, 303528987048]);
? ellpointtoz(e, [4458713781401/835903744,
-64466909836503771/24167649046528])
%6 = 0.2765620403
? \p 32
realprecision = 38 significant digits (32 digits displayed)
? e = ellinit([1, 0, 1, -85357462, 303528987048]);
? ellpointtoz(e, [4458713781401/835903744,
-64466909836503771/24167649046528])
%8 = 0.27656204014107061464076203097
}}}
With the smaller precision, Pari knows that the result is not accurate to
its current 16 displayed decimals, and prints only 10 of them (of which
only the last is wrong). We also see that Sage's result with 100 bits of
precision has only 14 accurate decimals (less than half of what we asked
for).
Possible solutions:
1. add a flag {{{algorithm}}} to {{{elliptic_logarithm}}} and set it to
"pari" by default; given the loss of precision that even Pari's more
accurate algorithm seems to suffer, we might want to ask it to do the
computations with slightly higher precision than we need
2. find where Sage's algorithm loses so much precision and fix it
I tend towards doing 1 right now and working on 2.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/4214>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
