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)

📝 Checklist

• The title is concise and informative.
• 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]

Documentation preview for this PR (built with commit 0d55f83; changes) is ready! 🎉
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.

[user202729]

looks sane. Technically max_asymp_coeffs's removal is a breaking change, but I don't think anyone is bothered.

can probably remove in def dokchitser in src/sage/schemes/elliptic_curves/lseries_ell.py too. (why is the method named like this)

src/sage/lfunctions/pari.py looks quite internal (returns pari object?) but it has been like that before this PR, so okay.

[mantepse]

What do you think about the misnomer num_coeffs (now n_coeffs)? I think it's a bad idea to introduce an alias for that.

[fchapoton]

Martin, would you be more happy with "n_needed_coeffs" or "n_required_coeffs" ?

Do you object to "n_coeffs" because this is not a characteristic of the L-function but a data used in computation ?

Maybe one could just introduced and use the alias "cost" ?

[mantepse]

Martin, would you be more happy with "n_needed_coeffs" or "n_required_coeffs" ?

Not sure, but:

Do you object to "n_coeffs" because this is not a characteristic of the L-function but a data used in computation ?

yes. I think, in the long run it is better to keep n_ and friends to methods that count something. Of course, the method already has this misleading / unsuitable name. However, I think that introducing the alias makes it even harder to reach consistency and good names eventually.

Maybe one could just introduced and use the alias "cost" ?

That sounds very reasonable.

I should add that I really know nothing about L-series.