Update Simon's GP scripts

[John Cremona]

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

Denis Simon has new versions of his scripts (see ​http://www.math.unicaen.fr/~simon/), these should be updated (see src/ext/pari/simon).

[John Cremona]

applies to 4.7.alpha1

[John Cremona]

applies to 4.7.alpha1

[John Cremona]

Note to reviewers. It is very likely that you will find elliptic curves where the scripts do not work (I have some of my own). That is *not* a reason to reject this enhancement. The scripts are not perfect, but they are all we have over number fields! As a result of this ticket, we get both updated version of the scripts (with some bug-fixes and enhancements) and also faster execution. But not perfection.

[John Cremona]

Not yet ready for review: still testing.

[John Cremona]

New spkg

[Martin Raum]

I created a new spkg and I updated the way to update import the library, removing one GP-script from the spkg. I can give this a positive review, but before someone needs to test this on Mac at least.

[John Cremona]

Martin, the spkg at ​http://sage.math.washington.edu/home/mraum/simon-20110321.spkg seems to be identical to my original one, which cannot be right.

[Martin Raum]

I checked this, but indeed this is the right package. The point was to update the spkg-install script. The rest of the spkg, I think is perfect. Well, we should incorporate the new scripts that you received by Simon.

[Jeroen Demeyer]

Note that adding a new standard spkg to Sage would at least require changing some files in SAGE_ROOT, in particular spkg/install and spkg/standard/deps.

[Jeroen Demeyer]

I don't see much reason for this a separate spkg. Given that it is essentially one .c file, could we not put this into the main Sage library?

[John Cremona]

Replying to jdemeyer:

I don't see much reason for this a separate spkg. Given that it is essentially one .c file, could we not put this into the main Sage library?

I think that is a great idea. Putting it into an spkg seemed simpler as a way to work on it and test it, but I would be very happy to put it into the library. I guess that can be done by applying patches to the right places (the usual Sage library, but where else? ) and then would "sage -b" be enough to include it while testing?

[Jeroen Demeyer]

Replying to cremona:

I think that is a great idea. Putting it into an spkg seemed simpler as a way to work on it and test it, but I would be very happy to put it into the library. I guess that can be done by applying patches to the right places (the usual Sage library, but where else? ) and then would "sage -b" be enough to include it while testing?

You would need to edit also module_list.py. But I haven't given this idea much thought for now, I plan to work on this after 4.7 has been released.

[François Bissey]

Is this the main block to getting pari-2.5.0 in (I am aware there are also issues with lcalc on OS X but they seem to be actively worked on).

The description needs editing, it talks about two patches but there are three given. Plus point (1) doesn't make complete sense (it looks like some writing I could have done at 2am and forgot about).

[John Cremona]

I'll look at this again -- it was a lot of work (by Martin Raum, Henri Cohen and me) getting this to work at Sage Days in March, and a great disappointment that it then stalled.

But I don't think this affects the 2.5.0 issue; rather the contrary, I did not want to put more work into this one until the pari version was updated.

[Paul Zimmermann]

what are the work issues for that ticket?

Paul

[John Cremona]

This is the ticket I mentioned in my recent posting to the other ticket #9322.

I think I was waiting for Jeroen Demeyer who 5 months ago said he would look at it after 4.7 was released, but clearly had other things to do (as have I). I'll add it to my list of things to do.

One issue I do remember is that to make Simon's scripts work here we did a lot of editing of them (to make them correctly compile with gp2c), and told Simon what we had done, then as a result he made a new version which was already gp2c-compatible. So then someone (probably me) has to compare the versions so as to merge our changes, in effect. For example, one set of changes I made was to have all the top-level functions take as parameters all the parameters which Simon currently sets using global gp variables; this made his functions a lot cleaner to use.

[Martin Raum]

This patch works in the sense that most tests pass. There is, though, still work to be done.

[John Cremona]

I am now working on correcting the doctests (so not ready for review yet).

[Peter Bruin]

This branch updates Denis Simon's GP scripts to versions 06/04/2011 (ell.gp) resp. 13/01/2014 (ellQ.gp, ellcommon.gp [new], qfsolve.gp, resultant3.gp). The scripts themselves were copied unchanged from Simon's website (http://www.math.unicaen.fr/~simon/).

Summary of the other changes:

• change Qfsolve and Qfparam to qfsolve and qfparam
• remove one doctest in gp_simon.py that is also in ell_rational_field.py
• remove # random output in ell_number_field.py; if necessary we can add set_random_seed(0) before that, but I got the same output every time
• doctest fixes due to changed test output
• minor documentation fixes

Of course the real work in this ticket was done (indirectly) by Denis Simon, and I just made the necessary fixes to the Sage library, but it seems to me that the "Author" field is normally used for ticket authors rather than authors of any "upstream" code; do correct me if I'm wrong.

Jeroen has opened #15809 for the gp2c conversion; hopefully John and Martin's hard work can somehow be transplanted there!

[Volker Braun]

Doctest failures on 32-bit

• ​http://build.sagemath.org/sage/builders/%20%20slow%20Skynet%20cicero%20%28Fedora%2016%20i686%29%20full/builds/20/steps/shell_5/logs/stdio
• ​http://build.sagemath.org/sage/builders/%20%20slow%20Skynet%20mark%20%28SunOS%205.10-32%29%20full/builds/24/steps/shell_5/logs/stdio

[Jeroen Demeyer]

The pbori.pyx failure is from #15755.

[Jeroen Demeyer]

Why the dependency on #15483? Now both these tickets depend on eachother. I would prefer to fix #11005 first (using # 32-bit/# 64-bit) and then do #15483 on top of this.

[Jeroen Demeyer]

New commits:

​24b6fe9

Update Denis Simon's GP scripts to versions of 06/04/2011 (ell.gp)

[Peter Bruin]

Replying to jdemeyer:

Why the dependency on #15483?

Because #15483 is the obvious fix for the problem from comment:36.

Now both these tickets depend on eachother. I would prefer to fix #11005 first (using # 32-bit/# 64-bit) and then do #15483 on top of this.

I thought Git was supposed to make things like this easy. I knew that I made the two tickets depend on each other, of course, and agree that circular dependencies are in abstracto not very nice. However, in this case, what looks like a circular dependency is just a way of saying that the tickets should be merged together; the structure of the Git branches is still linear and easy to understand. Moreover, Git will automatically give the same result independently of the ordering in which the two branches are merged. I don't feel like spending any time on making each of the two tickets pass doctests separately.

I also realise you don't like the patch at #15483, so I will make a bit more propaganda for it.