John Cremona on Mon, 11 Dec 2023 11:23:19 +0100


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: getting strange ellheight() error for number field point and curve




On Sun, 10 Dec 2023 at 19:37, Bill Allombert <Bill.Allombert@math.u-bordeaux.fr> wrote:
On Tue, Dec 05, 2023 at 11:33:41PM +0100, Bill Allombert wrote:
> On Mon, Dec 04, 2023 at 05:25:32PM -0800, American Citizen wrote:
> > Hi:
> >
> > minimal m[1..5] = [1, 0, 0, -114223080, -283150929600]
> > pt=[29099, 4571616.001890359167852374954252793155119185143350555006071823347634514965562343989206397255762390603970823616017868766947483185076860275462218345407187946353537171824424767170799129381839037]
> > y=[-29099/2, 1/2, 84131656042917]
> > which is y = -29099/2 + 1/2 * sqrt(84131656042917)
> > p=[29099, Mod(1/2*a - 29099/2, a^2 - 84131656042917)]
> > point is on curve m [1, 0, 0, -114223080, -283150929600] --> 1
> > F[1] = [0, 0, 0, -5482707841/48, -244634179112639/864]
> > P[1] = [349189/12, Mod(1/2*a, a^2 - 84131656042917)]
> > is on curve: 1
> >
> > this works out good for all 8 curves and the point on the curve.
> >
> > NF = nfinit(a^2 - 84131656042917)
> > FN=ellinit(F[1],NF);
> > Then we try to find the height as ellheight(FN,pt)
> >   ***   at top-level: find_iso_hts(e)
> >   ***                 ^---------------
> >   ***   in function find_iso_hts: ... ellheight(FN,pt)");H[i]=
> >   ***   ellheight(FN,P[i]);pr
> >   ***   ^---------------------
> >   *** ellheight: impossible inverse in Fl_inv: Mod(0, 2).
>
> Alas, this is a bug in PARI
> (ellheight does not handle non-minimal models over a number field correctly).

There was three bugs actually...

I fixed them in the master branch.

NF = nfinit(a^2 - 84131656042917);
F1 = ellinit([0, 0, 0, -5482707841/48, -244634179112639/864],NF);
P1 = [349189/12, Mod(1/2*a, a^2 - 84131656042917)];
ellheight(F1,P1)
%4 = 20.912087636398176541299794149336289140

Also I added a check that points are really on the curve.

Thanks for reporting this bug, this function is difficult to test because it
is hard to find points over elliptic curves over number fields to test the
algorithm.

You can help yourself at https://www.lmfdb.org/EllipticCurve/.  Note that if you go to the home page of any curve, for example (random!) https://www.lmfdb.org/EllipticCurve/2.2.76.1/144.1/d/1, on the right-hand side you can see a link "Download all code to PariGP" which then shows you something like  https://www.lmfdb.org/EllipticCurve/2.2.76.1/144.1/d/1/download/gp which gives you the code to create that curve in gp and compute some of the quantities there.  I think that with recent (and perhaps not so recent) advances in pari, there are more pieces of code which we could include.

By the way, as ellbsd() was mentioned, I have a couple of comments: first that you cannot rely on having a global minimal model, as they do not always exist, so rather than having functions which give an incorrect answer when a model is not globally minimal, it is better (where possible) to adjust by the "difference" between the given model and a minimal model (which do of course exist locally).  When computing the BSD data for the LMFDB I have tried hard to get the details right, and have written some notes on this -- the most recent version is at https://github.com/JohnCremona/BSD/blob/master/BSD.pdf (the repository https://github.com/JohnCremona/BSD is public).  There, as well as explaining the normalisation issues which arise (and on which different authors do not agree) I give code snippets for hom to compute all te relevant quantities in Sage and Magma -- and of course I must add gp to that.   I will post to that list when I have done that -- or, as it is a pubclic repo, anyone here is welcome to edit the tex file and make a pull request!

John

 


Cheers,
Bill