#12509: computation of height of point on elliptic curve over Q(sqrt(5)) is 
WRONG
---------------------------------+------------------------------------------
       Reporter:  was            |         Owner:  was     
           Type:  defect         |        Status:  new     
       Priority:  critical       |     Milestone:  sage-5.6
      Component:  number theory  |    Resolution:          
       Keywords:                 |   Work issues:          
Report Upstream:  N/A            |     Reviewers:          
        Authors:                 |     Merged in:          
   Dependencies:                 |      Stopgaps:  #12692  
---------------------------------+------------------------------------------

Comment (by cremona):

 It seems to be a numerical stability problem.  With the same example, and
 using the first embedding of K, we have, first to default 53-bit
 precision:
 {{{
 sage: b2,b4,b6,b8
 (1.527864045, -128195.888575, -25017379.5417, -4118102250.56)
 sage: x
 -146.29844719
 sage: t
 -0.00683534254264
 sage: 1 - (b4 * t**2) - (2*b6 * t**3) - (b8 * t**4)
 3.5527136788e-15
 }}}
 while at 100-bit precision:
 {{{
 sage: bb2,bb4,bb6,bb8
 (1.5278640450004206071816526625, -128195.88857503147164756896321,
 -2.5017379541668653550777130780e7, -4.1181022505609323099570853156e9)
 sage: xx
 -146.29844718999242907073025207
 sage: tt
 -0.0068353425426405016233236537484
 sage: 1 - (bb4 * tt**2) - (2*bb6 * tt**3) - (bb8 * tt**4)
 3.5142315895588997690642550530e-15
 }}}
 This means that whenever we evaluate one of the four polynomials (which
 coefficients are essentially the b-invariants) at some point we may lose
 precision badly.

 One way out would be to use a "working precision" higher than the
 requested precision.  Another would be to use algebraic values instead of
 approximate ones for t,z,w in the algorithm, which is likely to be slow,
 but I will try it.

 A better solution for the longer term would be to implement Mestre's AGM
 algorithm instead BUT this only exists at present  for real embeddings (I
 have worked on extending to the complex case, but that is still in
 progress).

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12509#comment:7>
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 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.

Reply via email to