Karim Belabas on Fri, 19 Dec 2008 19:24:38 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Functions elllderiv and ellanalyticrank |
* 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] `