L-functions and modularity

[edgarcosta]

Hello,

I'm bit confused with how we compute/represent some of the L-functions in the LMFDB.

Let's look into:
http://www.lmfdb.org/L/ModularForm/GL2/Q/holomorphic/15/2/1/a/0/
http://www.lmfdb.org/L/EllipticCurve/Q/15.a/

One is computed on the fly, and the other one is extracted from the database.
But given that they are the same L-function, shouldn't we treat them the same way?
This leads to a lack of symmetry and modularity isn't clear at all:

• The L-function of the EC has an arithmetic normalization while the one from MF doesn't.
• The L-function of the MF is aware of the existence of the L-function of the Elliptic Curve, but the L-function of the EC is not aware of the L-function of the MF, however, is aware of the MF.

Further, shouldn't we clearly say that they are the same?
I understand that if we don't have a generic modularity proof for that class of objects, we don't want to say that they are the same, but we could say that they are conjecturally the same.
Or another way to put, shouldn't we precompute every L-function in the automorphic world and use the Lhash to match them with the L-functions of the motivic world? And perhaps allow more than one "initial" object? (and treat the L-function as one.)

Best,
Edgar

[davidfarmer]

We are in the midst of converting all the L-function from compute-on-the-fly to being
rigorously precomputed and stored in a database.

This issue is one of many which will be addressed once the modular forms L-functions are
in the database, and which are impossible (given our resources) to address now.

[edgarcosta]

Great!

Thanks for the quick reply.
Feel free to close this if it is already on some TODO list somewhere else.

[AndrewVSutherland]

The immediate critical issue identified above is fixed by #2717. The broader issue that objects with the same L-function should appear in each others list of related objects (in an automated way) is planned future work.