Maass eigenvalues shifted

[edgarcosta]

Some forms display the eigenvalues shifted, e.g.:
http://www.lmfdb.org/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c
vs
http://www.lmfdb.org/L/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c/

[davidfarmer]

If the form has weight 0 and is even, then the Gamma factors are Gamma_R(s \pm i R), and if it is odd then Gamma_R(s + 1 \pm i R). If the weight is 1, then the concept of even/odd does not apply, you get Gamma_R(s \pm i R) Gamma_R(s + 1 \mp i R) , but we don't have any of those in the LMFDB yet. If that is what you refer to, then probably everything is right (except that these facts need to be explained somewhere).

…

On Mon, 8 Oct 2018, Edgar Costa wrote: Some forms display the eigenvalues shifted, e.g.: http://www.lmfdb.org/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c vs http://www.lmfdb.org/L/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c/ — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.[AAM6LBiGIVOkkpMoKvCjqBsU8wxWbFKYks5ui3iWgaJpZM4XNPry.gif]

[edgarcosta]

I should have been clearer.

I'm referring to the fact that in the Maass Form page we display,
c_0 = 1
c_1 = 0.7071067
c_2 = 1.1982127
c_3 = 0.5
c_4 = -0.2131064

while, I believe we wanted to display:
c_1 = 1
c_2 = 0.7071067
c_3 = 1.1982127
c_4 = 0.5
c_5 = -0.2131064

[davidfarmer]

You are right: in both cases it should have c(0) = 0 and c(1) = 1. Brief poking around did not reveal a pattern to those which are wrong.

…

On Mon, 8 Oct 2018, Edgar Costa wrote: I should have been cleared. I'm referring to the fact that in the Maass Form page we display, c_0 = 1 c_1 = 0.7071067 c_2 = 1.1982127 c_3 = 0.5 c_4 = -0.2131064 while, I believe we wanted to display: c_1 = 1 c_2 = 0.7071067 c_3 = 1.1982127 c_4 = 0.5 c_5 = -0.2131064 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.[AAM6LPOm1gViYi10RlYfqfUb8Cjvquigks5ui4YjgaJpZM4XNPry.gif]

[AndrewVSutherland]

Looking at the level 2 forms I think the issue arises when the coefficients are stored in the mwf_forms table, see https://www.lmfdb.org/api/mwf_forms/?Level=2, What's weird is that the data looks consistent with many of the level 1 forms that have coefficients in mwf_forms, see https://www.lmfdb.org/api/mwf_forms/?Level=1, and these forms appear to display correctly.

@rbommel You looked at the relevant code most recently I think, any ideas?

[rbommel]

Yes, my code couldn't find these coefficients due to a rounding error. I fixed this now and made a pull request for that. For some reason the coefficients of this particular form seemed to be stored multiple times in the database. As usual, I have no idea why it is like this. If you download the coefficients, you just get the raw data which I retrieve from the database.

[AndrewVSutherland]

@rbommel But does that explain why the coefficient display on http://www.lmfdb.org/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c is shifted by 1? On your PR they still look shifted.

Also, it looks like your PR has a merge conflict.

[rbommel]

Strange, when I run it here, I get 'c(0) = 0' now. The reason why it is shifted, is because the coefficients are stored wrongly in mwf_forms apparently (if we believe @edgarcosta). In mwf_coeffs the first coefficient is a 0.

Yes, it told me about this conflict, but Github told me not to worry about it, so I didn't.

[AndrewVSutherland]

@rbommel Never mind, you are right it is fixed in your PR (I must have checkout out the wrong branch).

The merge conflict needs to be resolved before we can merge your PR, and I'd rather not do that by hand. Given how small and localized the change is, I might suggest getting your master up to date (pull from upstream), creating a new branch, and re implementing your more recent edits (possibly by copy and paste, but you'll want to be careful -- there is a reason github is complaining, possibly because a change you made in your last PR to the same section of code is not reflected in this PR).

[rbommel]

Okay, somebody seems to have added some parenthesis around a print statement. I just left them there. Should be fine now.

[AndrewVSutherland]

Fixed via #3536, thanks @rbommel !

[edgarcosta]

I know very little about mass forms. But given that c(p) are Dirichlet coefficients, that makes me expect c(0) = 0.

…

On Sat, 14 Dec 2019 at 21:29, Andrew Sutherland ***@***.***> wrote: Fixed via #3536 <#3536>, thanks @rbommel <https://github.com/rbommel> ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2647?email_source=notifications&email_token=AACO2BTBZSCG2GV5T46CQUDQYWI6PA5CNFSM4FZU7LZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4PYBA#issuecomment-565771268>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACO2BTQNMUWW7N7FYPX3SLQYWI6PANCNFSM4FZU7LZA> .

[davidfarmer]

Similar to the holomorphic case: newforms have constant term 0. Eisenstein series have a nonzero constant term (at at least one cusp). We only want cusp forms (in particular, newforms) in the LMFDB.

…

On Sat, 14 Dec 2019, Edgar Costa wrote: I know very little about mass forms. But given that c(p) are Dirichlet coefficients, that makes me expect c(0) = 0. On Sat, 14 Dec 2019 at 21:29, Andrew Sutherland ***@***.***> wrote: > Fixed via #3536 <#3536>, thanks > @rbommel <https://github.com/rbommel> ! > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub ><#2647?email_source=notifications&email_token=AACO2BTBZSCG2G V5T46CQUDQYWI6PA5CNFSM4FZU7LZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4PYB A#issuecomment-565771268>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACO2BTQNMUWW7N7FYPX3SLQYWI6PANCNFSM4FZU7LZA> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, orunsubscribe.[AABTULCMEEBWULYVSPZ652DQYWOBDA5CNFSM4FZU7LZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH JKTDN5WW2ZLOORPWSZGOEG4QHHQ.gif]

[AndrewVSutherland]

@edgarcosta Did you notice any pages where c(0) != 0? In most cases (and certainly in the case of http://www.lmfdb.org/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c), c(0) is not even stored. Or are you suggesting c(0) should not be displayed at all? (if the latter I agree, but I don't think we should be investing any time any energy on improving the current UI, since the plan is to completely replace it, my only goal for 1.1.1 is to fix or hide anything that simply does not work or is mathematically incorrect (#2645, #2576, #2647, #2688, #2950, #3372 all fall into this category).

Having said that, if it is easy to do and someone is motivated to do it, I would be happy to see the c(0)=0 line go away.

[edgarcosta]

@AndrewVSutherland, just confirming that c(0) = 0 is what I expect, instead of what we displayed before http://prod.lmfdb.xyz/ModularForm/GL2/Q/Maass/54104e8dacf756699fe0830c