Normalization of bad local factors of symmetric powers

[davidfarmer]

On this page:
http://www.lmfdb.org/L/SymmetricPower/3/EllipticCurve/Q/50/a/
it says at the top that the page is in the analytic normalization,
but the bad local factors are shown in the arithmetic normalization.

But the value used in computing the L-function seems to be correct.

[AndrewVSutherland]

This will not be an issue once these L-functions are stored in the database (which we want to do as part of the general goal of getting all L-functions in the database so we can search on them -- see #3117)

[edgarcosta]

Symmetric powers are computed on the fly, and I don't think we will ever precompute them, as it would increase storage significantly, so I'm not sure this will be fixed by #3117

[jwj61]

Would it be a problem to have at least some of them in the database?

[davidfarmer]

I assumed we would have symmetric powers in the database for certain ranges of the parameters. Same principle as used to decide which modular forms L-functions to precompute.

…

On Mon, 3 Jun 2019, John Jones wrote: Would it be a problem to have at least some of them in the database? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute thethread.[AABTULFLSLJ4E3NLPJF3SELPYVXH5A5CNFSM4GPIV4G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPW SZGODW2O2BQ.gif]

[edgarcosta]

Is not a problem to have some of them in the database. On Mon, 3 Jun 2019 at 15:40, David W. Farmer <[email protected]> wrote:

…

I assumed we would have symmetric powers in the database for certain ranges of the parameters. Same principle as used to decide which modular forms L-functions to precompute. On Mon, 3 Jun 2019, John Jones wrote: > > Would it be a problem to have at least some of them in the database? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute thethread.[AABTULFLSLJ4E3NLPJF3SELPYVXH5A5CNFSM4GPIV4G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPW > SZGODW2O2BQ.gif] > > > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2694?email_source=notifications&email_token=AACO2BXEIUTXYCXLUBTFLETPYVXP3A5CNFSM4GPIV4G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2O7EY#issuecomment-498397075>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACO2BWBCKLN6DYV4Z3RKHLPYVXP3ANCNFSM4GPIV4GQ> .

[AndrewVSutherland]

We currently only provide links to L-functions of symmetric powers of elliptic curves of conductors < 50, see

http://www.lmfdb.org/L/degree3/EllipticCurve/SymmetricSquare/
http://grace.mit.edu/L/degree4/EllipticCurve/SymmetricCube/

Certainly these should all be in the database, and we can go much further than this. There are a lot of advantages to putting L-functions in the database (it makes them searchable, and we can make rigorous statements about precision, analytic rank bounds, etc...), and we really would like to have all L-functions up to some reasonable conductor bound stored in the database, even if they are easy to compute on the fly.

[edgarcosta]

We provide these for any elliptic curve over Q: http://www.lmfdb.org/L/EllipticCurve/Q/360/a/ http://www.lmfdb.org/L/SymmetricPower/2/EllipticCurve/Q/360/a/ however, for large conductor we don't compute everything anymore: http://www.lmfdb.org/L/EllipticCurve/Q/50001/a/ http://www.lmfdb.org/L/SymmetricPower/3/EllipticCurve/Q/50001/a/ I agree that having these in the database is worthwhile, the question is when to stop, as just these could increase the DB size by a serious magnitude factor. We could also take higher powers, or wedge squares for genus 2, as these will corresponds to L-functions of the Galois representation associated to the transcendental lattice of a K3 surface.

…

On Mon, 3 Jun 2019 at 21:32, Andrew Sutherland ***@***.***> wrote: We currently only provide links to L-functions of symmetric powers of elliptic curves of conductors < 50, see http://www.lmfdb.org/L/degree3/EllipticCurve/SymmetricSquare/ http://grace.mit.edu/L/degree4/EllipticCurve/SymmetricCube/ Certainly these should all be in the database, and we can go much further than this. There are a lot of advantages to putting L-functions in the database (it makes them searchable, and we can make rigorous statements about precision, analytic rank bounds, etc...), and we really would like to have all L-functions up to some reasonable conductor bound stored in the database, even if they are easy to compute on the fly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2694?email_source=notifications&email_token=AACO2BWO7QZCH4RDD4RS63LPYXAZZA5CNFSM4GPIV4G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3EOGY#issuecomment-498485019>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACO2BUNZH56NQG7WDTMLD3PYXAZZANCNFSM4GPIV4GQ> .

[AndrewVSutherland]

I think we should store in the database powers whose conductor falls within whatever our nominal conductor range is for that degree (e.g. 10^6 for degree 4, which would mean storing symmetric cubes of elliptic curves with conductor under 100, which is certainly not a problem). So I guess my answer to "when to stop" is wherever we already stop (which perhaps should be a bit higher than 10^6 in degree 4, since we do have plenty of imprimitive degree 4 rational L-functions coming from CMFs with conductors up to 10^8 stored in the database).

I'm not sure I see a lot of value in providing links to incomplete L-function pages for conductors outside our chosen range.