Re: Functions elllderiv and ellanalyticrank

[Karim Belabas <Karim.Belabas@math.u-bordeaux1.fr>]

* Bill Allombert [2008-12-19 17:28]:
> On Thu, Dec 18, 2008 at 11:04:17AM +0100, Xavier-François Roblot wrote:
> > Dear PARI-developers,
> > 
> > I have committed to the SVN version of PARI/GP two new functions called 
> > elllderiv and ellanalyticrank. These functions have been implemented by 
> > Christophe Delaunay and myself after a script of Tom Womack and John 
> > Cremona and using results from Henri Cohen's book GTM 239. As you might 
> > have guessed by now the first function computes the derivatives at s=1 
> > of the L-function of an elliptic curve, and the second one uses this 
> > computation to compute the analytic rank of an elliptic curve.
> > 
> > gp >  e = ellinit("11a1");
> > gp > ellanalyticrank(e)
> > %2 = [0, 0.2538418608559106843377589233]
> > gp >  e = ellinit("37a1");
> > gp >  ellanalyticrank(e)
> > %4 = [1, 0.3059997738340523018204836835]
> > gp >  e = ellinit("389a1");
> > gp > ellanalyticrank(e)
> > %6 = [2, 1.518633000576853540460385214]
> > gp >  e = ellinit("5077a1");
> > gp >  ellanalyticrank(e)
> > %8 = [3, 10.39109940071580413875185035]
> > 
> > Please try them out and let me know if you find any bugs and/or 
> > inefficiencies.
> 
> Hello Xavier,
> 
> This is a very nice patch. Here my comments:
> 
> 1) For all the curves in Cremona databases it returns the same as the
> geometric rank (for conductor <120000). This is very good (for your
> patch, for Cremona database and for Birch and Swinnerton-Dyer conjecture
> :))
> 
> 2) I think elllderiv should be renamed ellL1 for consistency with bnrL1
> (and maybe add a flag so that both functions have the same semantic).
> 
> 3) The fields of ELLLD should be documented.
> 
> 4) The function number_of_terms() take an argument 'prec' which is not
> used, but use DEFAULTPREC intensively.
> 
> 5) Instead of gzeta(stoi(i), prec), you can use szeta(i, prec).
> 
> 6) Error messages like pari_err(talker, "M is smaller than 2x\n")
> and pari_err(talker, "M1 is not valid upper bound\n");
> are meaningless. Please change them to someting meaningful. 
> (If they are internal error change "talker" to "bugparier").
> 
> 7) Please document what is VSX in #define VSX 5.
> (Or better remove VSX. One day someone will create a CPU called VSX and
> gcc with define VSX. It already appened with k6 and sgi.)
> 
> 8) you can use powuu isntead of gpowgs(stoi(n), r) if n and r are >0
> 
> 9) compute_Gr_Sx call timer2 but not msgtimer
> 
> 10) Use gerepilecopy instead of gerepileupto(av,gcopy())
> 
> 11) instead 
>   rep = cgetg(3, t_VEC);
>   gel(rep, 1) = gcopy(stoi(rk));
>   gel(rep, 2) = gcopy(Lr1);
>   return gerepileupto(av, rep);
> 
> It is better to do
>   return gerepilecopy(av, mkvec2(stoi(rk),Lr1));
> 
> 12) You use vs = fetch_user_var("s"); This is not great because this
> breaks the user space interface by creating varibale with unexpected
> priority.

Hi Bill, 

  thanks for looking at the patch and the detailed comments. I did look
at it too, but was too lazy to explain every single change; hence the
6 "cleanup" commits yesterday and this morning [ 11462 to 11468 ]

The current svn version already incorporates all the above (and many more),
except the second error message in 6). ( Which I believe is an
impossible situation but had no time to check yet.)

There are only two items left from my initial TODO list about this patch:

A) It still uses far too much memory, so that the "small" curves with
rank 7 (say) can't be handled with a PARI stack of 1GByte.

B) Once A) is no longer a problem (say, in about 40 minutes), check Tom
Womack's table at

  http://www.warwick.ac.uk/staff/J.E.Cremona/womack.html

Many interesting curves with "largish but tolerable" conductor...

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite Bordeaux 1          Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~belabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`