p-primary bound for Sha can be improved

[wuthrich]

This ticket aims to improve the p-adic bit of sha_tate for elliptic curves over Q.

• There are a few minor points to improve in the documentation (some of the conditions are not stated precisely or slightly wrong).

• We can now allow reducible primes, too. Since #6406 we ask for the p-adic rep to be surjective. However the recent results in [1] imply that the bounds are also correct for all odd primes of semi-stable reduction when the curve admits a p-isogeny.

• There is a small bug in padic_lseries, which made this fails:

  sage: E = EllipticCurve("5040bi1")
  sage: E.sha().p_primary_bound(5)
  

(reported by Charlene Soh).

[1] C Wuthrich, On the integrality of modular symbols and Kato's Euler system for elliptic curves. Doc. Math. 19 (2014), 381–402.

[wuthrich]

New commits:

​083af08	corrections in sha_tate
​e20fe26	trac #16959: doctests for corrections in sha_tate

[wuthrich]

Sorry for the noise. I reformated some of the docstrings. Not that much changes actually.

[was]

Please run doctests, e.g., -- your changes here impact the file BSD.py, causing 5 doctest failures:

/scratch/wstein/sage-6.4.beta0$ ./sage -t --warn-long 108.4 src/sage/schemes/elliptic_curves/BSD.py
Running doctests with ID 2014-09-10-16-21-02-4fc7534a.
Doctesting 1 file.
sage -t --warn-long 108.4 src/sage/schemes/elliptic_curves/BSD.py
**********************************************************************
File "src/sage/schemes/elliptic_curves/BSD.py", line 304, in sage.schemes.elliptic_curves.BSD.?
Failed example:
    EllipticCurve('11a').prove_BSD(verbosity=2)
Expected:
    p = 2: True by 2-descent...
    True for p not in {2, 5} by Kolyvagin.
    True for p=5 by Mazur
    []
Got:
    p = 2: True by 2-descent
    True for p not in {2, 5} by Kolyvagin.
    Kato further implies that #Sha[5] is trivial.
    []
**********************************************************************
File "src/sage/schemes/elliptic_curves/BSD.py", line 310, in sage.schemes.elliptic_curves.BSD.?
Failed example:
    EllipticCurve('14a').prove_BSD(verbosity=2)
Expected:
    p = 2: True by 2-descent
    True for p not in {2, 3} by Kolyvagin.
    Remaining primes:
    p = 3: reducible, not surjective, good ordinary, divides a Tamagawa number
        (no bounds found)
        ord_p(#Sha_an) = 0
    [3]
Got:
    p = 2: True by 2-descent
    True for p not in {2, 3} by Kolyvagin.
    Kato further implies that #Sha[3] is trivial.
    []
**********************************************************************
File "src/sage/schemes/elliptic_curves/BSD.py", line 318, in sage.schemes.elliptic_curves.BSD.?
Failed example:
    EllipticCurve('14a').prove_BSD(two_desc='simon')
Expected:
    [3]
Got:
    []
**********************************************************************
...

[was]

In elliptic_curves, the only failures are in BSD.py:

/scratch/wstein/sage-6.4.beta0$ ./sage -tp 12 --long src/sage/schemes/elliptic_curves/ 
...
---------------------------------------------------------------------
sage -t --long --warn-long 101.9 src/sage/schemes/elliptic_curves/BSD.py  # 5 doctests failed
----------------------------------------------------------------------
Total time for all tests: 171.4 seconds
    cpu time: 814.7 seconds
    cumulative wall time: 909.4 seconds

[was]

I ran all tests ('make ptestlong') across sage, including the documentation, and this is what I got:

----------------------------------------------------------------------
sage -t --long --warn-long 104.2 src/doc/en/bordeaux_2008/elliptic_curves.rst  # 1 doctest failed
sage -t --long --warn-long 104.2 src/sage/schemes/elliptic_curves/BSD.py  # 5 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1106.0 seconds
    cpu time: 10570.1 seconds
    cumulative wall time: 12252.5 seconds
make: *** [ptestlong] Error 1
/scratch/wstein/sage-6.4.beta0$  

Aside from fixing that, I am happy with this "patch" (having read it).

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​45eca3d

trac #16959: adjusting doctests

[wuthrich]

Sorry for the sloppy work. Now I adjusted these two and all tests pass.

I had to change William's presentation in Bordeaux. Now there are two more or less identical examples. I thought it better not to change the example though.

[was]

It now looks perfect... except why did you delete the periods after our first initials in this diff (e.g., "W. Stein" --> "W Stein"):

diff --git a/src/sage/schemes/elliptic_curves/BSD.py b/src/sage/schemes/elliptic_curves/BSD.py
index 0b26f34..f496ccb 100644
--- a/src/sage/schemes/elliptic_curves/BSD.py
+++ b/src/sage/schemes/elliptic_curves/BSD.py
@@ -290,9 +290,9 @@ def prove_BSD(E, verbosity=0, two_desc='mwrank', proof=None, secs_hi=5,
        Hautes Études Sci. Publ. Math. No. 47 (1977), 33--186 (1978).
     .. [Rubin] K. Rubin. The "main conjectures" of Iwasawa theory for
        imaginary quadratic fields. Invent. Math. 103 (1991), no. 1, 25--68.
-    .. [SteinWuthrich] W. Stein and C. Wuthrich. Computations about
-       Tate-Shafarevich groups using Iwasawa theory.
-       http://wstein.org/papers/shark, February 2008.
+    .. [SteinWuthrich] W Stein and C Wuthrich, Algorithms
+       for the Arithmetic of Elliptic Curves using Iwasawa Theory
+       Mathematics of Computation 82 (2013), 1757-1792.
     .. [SteinEtAl] G. Grigorov, A. Jorza, S. Patrikis, W. Stein,
        C. Tarniţǎ. Computational verification of the Birch and
        Swinnerton-Dyer conjecture for individual elliptic curves.

[was]

(switching to positive review -- the dots are a triviality).

[vbraun]

Fails on 32-bit:

sage -t --long src/sage/schemes/elliptic_curves/sha_tate.py
**********************************************************************
File "src/sage/schemes/elliptic_curves/sha_tate.py", line 768, in sage.schemes.elliptic_curves.sha_tate.Sha.p_primary_bound
Failed example:
    e.sha().p_primary_bound(7)
Exception raised:
    Traceback (most recent call last):
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 480, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 843, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.schemes.elliptic_curves.sha_tate.Sha.p_primary_bound[13]>", line 1, in <module>
        e.sha().p_primary_bound(Integer(7))
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/sha_tate.py", line 805, in p_primary_bound
        shan = self.an_padic(p,prec = 0,use_twists=True)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/sha_tate.py", line 577, in an_padic
        lp = Et.padic_lseries(p)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/padics.py", line 158, in padic_lseries
        normalize = normalize, use_eclib=use_eclib)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/padic_lseries.py", line 197, in __init__
        self._modular_symbol = E.modular_symbol(sign=+1, use_eclib = use_eclib, normalize=normalize)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py", line 1208, in modular_symbol
        M = ell_modular_symbols.ModularSymbolECLIB(self, sign, normalize=normalize)
      File "/home/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/sage/schemes/elliptic_curves/ell_modular_symbols.py", line 500, in __init__
        self._modsym = ECModularSymbol(E)
      File "sage/libs/cremona/newforms.pyx", line 70, in sage.libs.cremona.newforms.ECModularSymbol.__init__ (build/cythonized/sage/libs/cremona/newforms.cpp:2310)
    OverflowError: Python int too large to convert to C long
**********************************************************************

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​cfc4371

Merge branch 'develop' into sha

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​93d4572

trac #16959: change doctest for 32 bit

[vbraun]

Just documenting that it doesn't work on 32bit is not really a desirable fix...

[wuthrich]

I hope this would solve it, though I can't test 32-bit.

This 32-bit issue is linked to eclib having problems with 32-bit. I copied # 32-bit as I did earlier in #11211, where Paul Zimmermann noticed "However there are already some tests that are known to fail on 32-bit, for example in lib/cremona/newforms.pyx: ...". At the time I did not see any other solution than to make 32-bit fail. I don't know if the state has evolved since then.

If so that should be solved on a different ticket. This ticket here removed one example of this #32-bit behaviour and replaced it with another.

[vbraun]

John, do you care to comment on this? ;-)

I'm fine with making it a separate ticket, but then make sure that there *is* a separate ticket for that issue and link to it.

[cremona]

I am wondering why Chris removed me from the CC field....in nay case I received the email when I was added, and now I have written on the ticket so you cannot get rid of me!

I think this can be fixed by changing lines 66-70 of sage/libs/cremona/newforms.pyx:

        a1 = new_bigint(int(E.a1()))
        a2 = new_bigint(int(E.a2()))
        a3 = new_bigint(int(E.a3()))
        a4 = new_bigint(int(E.a4()))
        a6 = new_bigint(int(E.a6()))

Here the E.a1() etc are Sage integers, and they need to be converted into eclib bigints which are exactly NTL ZZs. This should be possible without going via Python ints. The new_bigint function is defined near the top of defs.pxi is a long --> ZZ conversion (just NTL's to_ZZ). If nothing else, I think NTL can convert decimal strings to ZZs so you could try just replacing "int" with "str" in those 5 lines?

[wuthrich]

I did not "remove" you, of course. But I am puzzled that you were not added when I chose the component. Sorry John.

That would be great if we can can get rid of these 32-bit exceptions. There are 3 such examples in sha_tate and one in newforms, not sure if there are any others, but I could not grep any others....

I am fine if you want to do these changes on this present ticket as wel even if the issue is slightly different. Probably a separate ticket makes more sense. However, I fear I can help out because I have no access to a 32-bit machine to test this.

[cremona]

I think it would be best to do this on a separate ticket. I can test it on my 6.5-year-old laptop. See #16977. It will not be done immediately since I am still catching up after 2 weeks away, and don't have the laptop in my office anyway.

[vbraun]

If you make the edit then I can test it on the 32-bit buildbot...

[wuthrich]

ping!

(this should get reviewed as it is in 64bits and 32bits, please. Later the doctests 32-bit can be removed again in #16977.)

[pbruin]

Working on a reviewer patch (docstring improvements and doctest updates after #16977).

[pbruin]

The reviewer patch mostly fixes formatting and typos in docstrings. All tests pass, time to put it back to positive review.