Elliptic curve isogenies over number fields II: implement Billerey's algorithm for reducible primes

[JohnCremona]

This follows in from #22343 which is a dependency. We implement Billerey's algorithm for finding the set of reducible primes for an elliptic curve without CM over a number field. This is based on an implementation by Ciaran Schembri for a masters' project at Warwick.

CC: @adeines @kedlaya

Component: elliptic curves

Keywords: isogenies

Author: John Cremona

Branch/Commit: 2423f7a

Reviewer: Frédéric Chapoton

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

[adeines]

Branch: u/aly.deines/elliptic_curve_isogenies_over_number_fields_ii__implement_billeray_s_algorithm_for_reducible_primes

[adeines]

Commit: bfe5ca4

[adeines]

comment:2

I started putting Cremona's code for Billerey's algorithm into appropriate places in Sage. I cleaned it up a bit and addes some documentations.

Things left to do or fix:

• add documentation
• only works if the curve has integral discriminant
• incorporate into isogeny finding for EC's over number fields
• more examples, especially over larger fields
• timings against other methods
• probably more . . .

[adeines]

Changed keywords from none to isogenies

[JohnCremona]

comment:5

Thanks for the work so far. I'm working on this again now and will go through your to-do list.

[JohnCremona]

comment:6

I have rearranged the code quite a bit. The technical parts of Billerey I though were better kept separate and not as methods of the elliptic curve class itself, so I put them in gal_reps_number_field.py. (Alternatives were a new file, or on isogeny_class.py.) In isogeny_class.py I also refactored the code to produce a finite set of primes, separating out the cm case, and allowing the user a choice of 3 algorithms, Billerey, Larson or 'heuristic', the latter being non-rigorous, just testing all primes up a to a given bound to see if they passthe necessary local conditions. This is never the default and the docstring makes it clear that the output is not guaranteed complete.

This leaves a much simplified method reducible_primes() in the elliptic curves class itself, while the isogeny class code uses the new function to find the reducible primes, with Billerey the default algorithm.

I could put in more examples if desired. I have not done systematic timing tests, but note that until the work done on another ticket Larson's method could not handle fields of degree 5 and up at all.

While writing this I realised that I have not yet provided the possibility for E.isogeny_class() to use a non-default algorithm, and will add that, but I'll leave the ticket at "needs review" so that patchbots get working on it.

[JohnCremona]

Changed branch from u/aly.deines/elliptic_curve_isogenies_over_number_fields_ii__implement_billeray_s_algorithm_for_reducible_primes to u/cremona/22345

[JohnCremona]

Changed commit from bfe5ca4 to 1a1e7a6

[JohnCremona]

comment:7

Some timings: with z=zeta_101 and E=[0,1,0,z,z], reducible_primes_naive(E) with default parameters (max_l=1000, num_P=100) returns [2, 607] in 2m, while reducible_primes_naive(E, max_l=2000, num_P=200) returns [2] in about the same time (starting from scratch; if you do the second right after the first it is faster since some previous work is cached).
Working on this example revealed something stupid only indirectly relevant to this ticket: computing the 2-isogeny takes for ever! The stupid reason is that after computing the isogenous curve it tries to compute its global_minimal model. Which involves computing the class group of K.....
That needs fixing somehow but on a different ticket.

[sagetrac-git]

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

d3643b5

#22345 improved e.c. isogenies over number fields

[sagetrac-git]

Changed commit from 1a1e7a6 to d3643b5

[JohnCremona]

comment:9

The last commit makes several improvements after more testing. In Billerey's algorithm itself the improvement is to only use B. to find reducible primes greater than some lower bound (default 200) which never occur in practice, using the local test for smaller primes. Secondly, after noticing that some "easy" examples were taking forever on account of class group computations (which in turn are triggered by the conversion to global minimal models) I added a minimal_models flag which defaults to True to give the old behaviour but which can be set to False. New doctest to illustrate this are added. This flag had to be put into dozens of places from the top-level E.isogeny_class() down through various layers to the underlying isogeny code.

I am currently checking that all the additional docstrings compile OK...

[sagetrac-git]

Changed commit from d3643b5 to 252f048

[sagetrac-git]

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

252f048

#22345 fixed some bad docstrings

[jpflori]

comment:14

Looks like this need rebasing, or is it only trac's git which is not smart enough?

[JohnCremona]

comment:15

I'll rebase. I thought it was based on a recent version but maybe not

[sagetrac-git]

Changed commit from 252f048 to 645c6b7

[sagetrac-git]

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

70b8f12	Merge branch 'develop' into 22345
645c6b7	#22345 rebase + small speedup

[JohnCremona]

comment:17

That took longer than expected. The rebase was easy but when I tested all of schemes/elliptic_curves there was a long time warning coming from a test in kraus.py, relating to an earlier fix for #20737, marked as 15s but taking a minute (in semi_global_minimal_model()). I am not sure where the regression came from (not at all to do with this ticket, which in fact makes it possible for semi_global_minimal_model() not to be called when computing isogenies, precisely for the reason that it can take too long when the class group is large). I did two things which help: first, use prime_range() instead of primes() in the primes_of_bounded_norm methods for number fields, and secondly to use a larger bound when searching for a prime in an ideal class -- since if it fails it doubles the bound, which is of course wasteful since the small ones are re-tested. If the resulting time (25s for me for this test) is deemed too long we can mark it 'not tested', but it is there precisely because this case is a hard one.

[adeines]

Changed branch from u/cremona/22345 to u/aly.deines/22345

[JohnCremona]

Changed commit from 645c6b7 to 51c21c3

[JohnCremona]

comment:20

Aly can you explain the branch change you made on Aug 24 which I only just noticed? I cannot read your branch (it shows on trac but not as a link) so I don't know what you changed.

---

New commits:

51c21c3

Merge branch 'u/cremona/22345' of git://trac.sagemath.org/sage into t/22345/22345

[fchapoton]

comment:21

branch does not apply

[JohnCremona]

comment:22

I have merged in 8.3.rc0, fixed conflicts and checked that all tests pass. I hope I will not have to do this again a year from now!

---

New commits:

94f7114

Merge branch 'develop' into 22345

[JohnCremona]

Changed branch from u/aly.deines/22345 to u/cremona/22345

[JohnCremona]

Changed commit from 51c21c3 to 94f7114

[fchapoton]

Changed branch from u/cremona/22345 to public/ticket/22345

[fchapoton]

Reviewer: Frédéric Chapoton

[fchapoton]

comment:23

Please look at my commit, fixing some details about py3:

• using r""" for documentation containing latex operators

• do not use .next

If you agree with my changes, you can set to positive.. But I do not claim anything about checking the math, so you may want to wait for an expert's opinion.

---

New commits:

2423f7a

trac 22345 some details (py3 compatibility, please)

[fchapoton]

Changed commit from 94f7114 to 2423f7a

[JohnCremona]

comment:24

I am happy with your changes. Thanks. I have discussed the ideas here with people who have not actually looked at the code in detail. I think the only reasonable thing to do is to get it merged so that it gets used (if there is anyone out there interested). I have used this a lot in computing isogeny classes of curves for the LMFDB, which is how I found out that the old code in Sage was completely useless over number fields of degree >4.

[vbraun]

Changed branch from public/ticket/22345 to 2423f7a