Closed JohnCremona closed 9 years ago
Replying to @jdemeyer:
Replying to @JohnCremona:
It's pretty shocking that to take a list of 4 elliptic curves and compute their j-invariants and count the distinct ones takes a long time! Even if it is over a number field of degree 6. But so be it.
No no, it is because those 2 tests depend on an earlier
# long time
test. The following doesn't work:sage: x = answer_to_the_ultimate_question() # long time (7.5 million years) sage: x 42
If you run this without
--long
the first line will be skipped and the second line will therefore fail.
Of course, my stupidity.
Note to potential reviewers: Jeroen has reviewed the Sage-technical aspects of this, but we need someone to vouch for its mathematical correctness. For curves without CM there was little to do given the dependent tickets (now closed) which give the finite list of prime degrees to test, as the structure of the code already existed for curves over Q. The main thing which needs to be looked at is the CM case, where I had to work out several things myself, not knowing of suitable references.
I spotted that one of the commits of #16806 does not seem to be included in this :
https://github.com/sagemath/sagetrac-mirror/commits/8c9301671b354f7ba6c24d48f28d0e2b0698f39f
Not sure this is important, but it seems the right thing to include it if it is depending on that ticket.
I fear I won't have time to check the maths anytime soon. But I put it on my list of things to do.
Replying to @JohnCremona:
Note to potential reviewers: Jeroen has reviewed the Sage-technical aspects of this
To be more precise, let's say I reviewed everything outside of src/sage/schemes/elliptic_curves
While skimming through the rest of the patch, I just noticed several # not tested
for the graphs. Any reason?
You are right, and while think the system would deal with this automatically (it's your addition to include new stuff in the ref manual, right?) I'll merge that in.
Changed branch from u/jdemeyer/ticket/16743 to u/cremona/ticket/16743
Sorry, my comment was in reply to Chris. I have merged in the commit he mentioned (and then switched back the branch of this ticket to my name, ha ha).
To answer Jeroen: I think I was under the impression that displaying graphs during testing would create problems, while it is nice to have the examples in the manual. If it is harmless then we can remove these tags.
A quick look at the doc output shows quite a few problems in isogeny_class of elliptic curves over number fields.
Replying to @categorie:
A quick look at the doc output shows quite a few problems in isogeny_class of elliptic curves over number fields.
Apologies. I will sort that out, no need for you to.
Replying to @JohnCremona:
I was under the impression that displaying graphs during testing would create problems, while it is nice to have the examples in the manual. If it is harmless then we can remove these tags.
Please do! Graphics objects are doctested by plotting them to a temporary file. It's good to have those tests, since they check that plotting works (to some extent, it's not checked how the picture looks like).
Note that this plotting machinery might take a while, so it would be prudent to add # long time
to those plotting tests.
Branch pushed to git repo; I updated commit sha1. New commits:
542460d | #16743: fix doc output problem and turn on isogeny graph tests |
OK, I fixed the documentation display problem in ell_number_field (and a typo), and changed the "not tested" graph displays with "long time" which revealed 2 typos there which have been fixed (I had a matplotlib parameter as "edges_labels" twice.
Next!
New commits:
542460d | #16743: fix doc output problem and turn on isogeny graph tests |
Branch pushed to git repo; I updated commit sha1. New commits:
33da411 | Merge branch 'develop' into isogs-ecnf |
ping!
Changed reviewer from Jeroen Demeyer to Jeroen Demeyer, Chris Wuthrich
pong!
I thought I would improve the documentation a little bit by including the isogeny class file into it. Other than that I can't see any reason to object against this ticket.
I am running the tests now.
As to the mathematics in here. Well, there is a lot and not all is trivial. I have read most of the new code, but I won't be able to verify everything. So my review is to confirm that John does very good work and that I have no doubts that it is as good as it can be.
New commits:
a3cca91 | Merge branch 'develop' into ticket/16743 |
79fee2d | trac 16743: changes to doc |
Changed branch from u/cremona/ticket/16743 to u/wuthrich/ticket/16743
Thanks, Chris. Of course there may well still be bugs, as always. The code was tested against completely independent determination of complete isogeny classes for a lot of curves over Q(sqrt(5)) and the cubic field of discriminant -23, and we find the same curves. That did not test the hardest part (namely the CM cases) though where I have done some systematic testing over imaginary quadratic fields of class number 1.
The tests passed.
I also played a bit around. Seems all ok to me.
Changed branch from u/wuthrich/ticket/16743 to 79fee2d
If E is an elliptic curve over QQ then E.isogeny_class() is an object of type (class) IsogenyClass_EC which which one can work in a nice way. This should be extended to number fields. Two reasons why this is notn-trivial (and hence was not done at the same time as over QQ): (1) bounding the possible primes degrees of isogenies; (2) handling curves with CM. For (1), the module
gal_reps_number_field
does what is required. For (2) new code has been written.Depends on #11327 Depends on #16764 Depends on #16806
Component: elliptic curves
Keywords: isogeny class
Author: John Cremona
Branch/Commit:
79fee2d
Reviewer: Jeroen Demeyer, Chris Wuthrich
Issue created by migration from https://trac.sagemath.org/ticket/16743