Ticket #10745 (new defect)

Opened 2 years ago

Last modified 2 years ago

bug in elliptic curve gens()

Reported by: rlm Owned by: cremona
Priority: major Milestone:
Component: elliptic curves Keywords:
Cc: aly.deines, cremona, gagansekhon, weigandt, was, wuthrich, robertwb Work issues:
Report Upstream: N/A Reviewers:
Authors: Merged in:
Dependencies: Stopgaps:

Description

sage: a = [1, 0, 1, -1751, -31352]
sage: F = EllipticCurve(a)
sage: K.<d> = QuadraticField(5)
sage: FK = EllipticCurve(K, a)
sage: F.gens()
[(52 : 111 : 1)]
sage: FK.gens()
[]

This isn't very good, because the default in Sage is proof=True, so one would expect this to be a provable result (until reading the docs of course. But if we try to look harder for the point, we run into a bug with caching:

sage: FK.gens(lim1=6)
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)

/home/rlmill/<ipython console> in <module>()

/home/rlmill/sage-4.6.2.alpha2/local/lib/python2.6/site-packages/sage/schemes/elliptic_curves/ell_number_field.pyc in gens(self, verbose, lim1, lim3, limtriv, maxprob, limbigprime)
   1772         """
   1773 
-> 1774         lower,upper,gens = self.simon_two_descent(verbose=verbose,lim1=lim1,lim3=lim3,limtriv=limtriv,maxprob=maxprob,limbigprime=limbigprime)
   1775         return gens
   1776 

/home/rlmill/sage-4.6.2.alpha2/local/lib/python2.6/site-packages/sage/schemes/elliptic_curves/ell_number_field.pyc in simon_two_descent(self, verbose, lim1, lim3, limtriv, maxprob, limbigprime)
    265         
    266         try:
--> 267             result = self._simon_two_descent_data[lim1,lim3,limtriv,maxprob,limbigprime]
    268             if verbose == 0:
    269                 return result

KeyError: (6, 50, 10, 20, 30)

So two problems: 1) Over Q, if the result is not provable a RuntimeError? is raised. This should be the same here. 2) One can't change parameters due to the way the output is being cached.

Change History

comment:1 Changed 2 years ago by cremona

I'm not sure that, when the gens() function was added over number fields at SD22, we thought it through very well. In particular, I don't think that Simon's code necessarily passes the "proof=True" criteria (but cannot be more specific). Except that the points it returns are points on the curve...

comment:2 Changed 2 years ago by cremona

The output of simon_two_descent() for EK is

sage: FK.simon_two_descent()
(1, 1, [])

which can be interpreted as follows: he computes the 2-Selmer rank is 1, which gives a valid upper bound for the rank (=1). He fails to find points on 2-coverings, so there are no points returned. *But* he uses the parity conjecture to increase the lower bound from 0 to 1.

So when we decide (in the simon_two_descent()) method) that the output is certain, we need to take this into account.

Secondly, the gens() function for curves over number fields is completely reckless:

        lower,upper,gens = self.simon_two_descent(verbose=verbose,lim1=lim1,lim3=\
lim3,limtriv=limtriv,maxprob=maxprob,limbigprime=limbigprime)
        return gens

There is no caching, no checking of Proof, and worst of all, the gens which are returned have not been looked at at all. Just about all you can say about them is that they are points on the curve.

Who let that in? This function needs changing urgently.

comment:3 Changed 2 years ago by wuthrich

  • Cc wuthrich added

comment:4 Changed 2 years ago by weigandt

  • Cc robertwb added

If we want to keep a gens() function for elliptic curves over number fields. We're going to need some functionality to check saturation of points over number fields. I'm ccing Robert Bradshaw because he's thought about this.

Note: See TracTickets for help on using tickets.