using pari for elliptic and Eisenstein L-series

[fchapoton]

trying to move away from Dokchitser's auld scripts

• no longer allowing their use for elliptic curves
• same in L-function of number fields
• same in L-function of the modular form Delta
• trying to get rid of them for Eisenstein L-functions
• trying to get rid of them for Gross-Zagier L-functions

help welcome !

Note: the handling of general modular forms is best kept for another pull request.

EDIT: also changing the method num_coeffs to n_coeffs for global coherence (old name kept as an alias)

:memo: Checklist

• [x] The title is concise and informative.
• [x] The description explains in detail what this PR is about.
• [ ] I have linked a relevant issue or discussion.
• [ ] I have created tests covering the changes.
• [ ] I have updated the documentation and checked the documentation preview.

[fchapoton]

@JohnCremona : I would appreciate help from Lmfdb and Pari experts on the case of Eisenstein series

[fchapoton]

Is this a failure or an improvement ?

File "src/sage/modular/modform/eis_series.py", line 422, in sage.modular.modform.eis_series.?
Failed example:
    L(2)
Expected:
    -5.0235535164599797471968418348135050804419155747868718371029
Got:
    -5.0235535164599799477225675531508296063579361580211036347215

ANSWER: this was a failure

[JohnCremona]

I'll look but not until Thursday

[fchapoton]

now there are some issues with the handling of bit precision..

and more precisely with the number of terms required, that are insufficient to check the functional equation

[fchapoton]

I am also annoyed because for Eisenstein series the only path I found to relative success was to pass the residue of the uncompleted L-function to pari, instead of the simpler residues of the completed L-function.

[fchapoton]

now remains only a failure

Expected:
    -5.0235535164599797471968418348135050804419155747868718371029
Got:
    -5.0235535164599800135315437325373372537800575000382643457910

which is apparently really a failure, as the expected value is

sage: f=zeta(2)*zeta(-17)
sage: f.n(200)
-5.0235535164599797471968418348135050804419155747868718371029

[fchapoton]

It seems to me that the handling of precision is still faulty, but I cannot investigate further.

[user202729]

the precision issues are mostly correct already? maybe just one # rel tol 1e-14 at L(2) + E.lseries_gross_zagier(A^2)(2) (if no explicit precision parameter are passed then one can expect roughly 53 bits)

[fchapoton]

@JohnCremona and @roed314 : would you please advertise to LMFDB people what I am trying to do here, namely get rid of the original Dokchitser scripts in favor of PARI ?

[github-actions[bot]]

Documentation preview for this PR (built with commit c4c98b05317a86db58777a4bac4c2cfe626b3b9b; changes) is ready! :tada: This preview will update shortly after each push to this PR.

[JohnCremona]

Documentation preview for this PR (built with commit af8a5e5; changes) is ready! 🎉 This preview will update shortly after each push to this PR.

I will leave this to @roed314 since he is, and I am no longer, a managing editor of LMFDB

[roed314]

I've advertised this PR on the LMFDB Zulip, and also sent @fchapoton an invitation to join (let me know if I got your address wrong: I took it from the Sage Zulip).

[mantepse]

after looking at the documentation, it seems to me that num_coeffs is a misnomer. It is not about the number of coefficients, it is an estimate of a certain cost:

        Return number of coefficients `a_n` that are needed in
        order to perform most relevant `L`-function computations to
        the desired precision.

the method calls lfuncost:

 estimate the cost of running
 lfuninit(L,sdom,der) at current bit precision. Returns [t,b], to indicate
 that t coefficients a_n will be computed at bit accuracy b. Subsequent
 evaluation of lfun at s evaluates a polynomial of degree t at exp(h s).
 If L is already an Linit, then sdom and der are ignored.

[fchapoton]

a related bug has just been fixed in PARI 2.17.3

[user202729]

what's the status of this? Is it ready for review?

not sure if some changes (e.g. removal of max_asymp_coeffs ) would be technically a breaking change (even though in practice it likely doesn't matter)

[fchapoton]

I think it should be ready.