bug in elliptic curve gens()

[rlmill]

[See #15608 for a list of open simon_two_descent tickets]

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).

Over Q, if the result is not provable an error is raised or a warning is printed, depending on the proof flag. This should be the same here.

Depends on #10735

CC: @adeines @JohnCremona @sagetrac-gagansekhon @sagetrac-weigandt @williamstein @categorie @robertwb

Component: elliptic curves

Author: Peter Bruin

Branch/Commit: 42c563c

Reviewer: Chris Wuthrich

Issue created by migration from https://trac.sagemath.org/ticket/10745

[JohnCremona]

comment:1

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...

[JohnCremona]

comment:2

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.

[sagetrac-weigandt]

comment:4

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.

[chriswuthrich]

comment:5

It seems that the second problem has disappeared in 6.0. I get now

sage: FK.gens(lim1=6)
[]

That still leaves 1).

Somehow, one should think that it would be best, if the curve remembered that it was defined over a smaller field and that it had found some points of infinite order already. In general, I think it is best if the algorithm would run through all subfield and search for points in there. ... But now I am dreaming.

[chriswuthrich]

comment:6

I modified the docstring of gens in #13593 . It now says there that the function returns some points of infinite order. In fact Simon's script just gives back what it came across during the various ways to search for points. They are not lin. indep. for instance. And of course there is no guarantee it finds any.

Maybe this ticket should now be rewritten as:

Implement gens correctly for elliptic curves over number fields. Extract from the points given by 2-descent (in case it determines the rank) a set of linearly indep. point and then saturate the Mordell-Weil group.

[JohnCremona]

Description changed:

--- 
+++ 
@@ -1,3 +1,4 @@
+[See #15608 for a list of open simon_two_descent tickets]
 
 ```
 sage: a = [1, 0, 1, -1751, -31352]

[chriswuthrich]

comment:8

I propose to close this after #13593 and #5153 as these two overlap a lot with the ticket here. Once they are closed. Then we open a new ticket enhancement for the saturation over number field (unless that exists already).

[pjbruin]

comment:9

Given that the documentation no longer says that the points returned by gens() are linearly independent or span a subgroup of full rank, this is technically not a bug anymore, but there is still the inconsistency with the similar function over Q. There seem to be three options:

1. close this ticket as invalid or wontfix;
2. use this ticket to print a warning or raise an error if gens() returns something other than a basis for a subgroup of full rank in the Mordell-Weil group;
3. rewrite this ticket with a more ambitious goal as in comment:6.
   Any ideas?

[pjbruin]

Description changed:

--- 
+++ 
@@ -10,31 +10,16 @@
 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).
 
-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:
+Over Q, if the result is not provable an error is raised or a warning is printed, depending on the `proof` flag. This should be the same here.
+
+In earlier versions of Sage (< 6.0), there was also 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
-
+Traceback (most recent call last):
+...
 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.

[jdemeyer]

Description changed:

--- 
+++ 
@@ -13,13 +13,3 @@
 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).
 
 Over Q, if the result is not provable an error is raised or a warning is printed, depending on the `proof` flag. This should be the same here.
-
-In earlier versions of Sage (< 6.0), there was also a bug with caching:
-
-```
-sage: FK.gens(lim1=6)
-Traceback (most recent call last):
-...
-KeyError: (6, 50, 10, 20, 30)
-```
-