Sign of HMF L-function

[davidfarmer]

There is some problem computing the Atkin-Lehner eigenvalue, resulting in a "sign" which does not have absolute value 1.

L/ModularForm/GL2/TotallyReal/2.2.104.1/holomorphic/2.2.104.1-5.2-c/0/0/

[jvoight]

This is actually a fairly serious issue, and I am resolving it with the help of Naomi Tanabe. The problem is that, as it turns out, some of the forms we have in the database do not have trivial central character when the narrow class group is nontrivial, coming about from how the quaternionic way these forms were computed. I am investigating.

At this point, I'm not sure if it makes sense to delete these forms from the database or to add functionality for nontrivial central character--I'm leaning toward the former.

[JohnCremona]

Might that include some dimension 1 newforms, for which I have not been able to find an elliptic curve?

On 26 March 2016 at 20:49, jvoight notifications@github.com wrote:

This is actually a fairly serious issue, and I am resolving it with the help of Naomi Tanabe. The problem is that, as it turns out, some of the forms we have in the database do not have trivial central character when the narrow class number is even: sometimes, a character of the Hilbert class group (trivial on the class group itself) intervenes, coming about from how the quaternionic way these forms were computed. I am investigating.

At this point, I'm not sure if it makes sense to delete these forms from the database or to add functionality for nontrivial central character--I'm leaning toward the former.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/396#issuecomment-201928498

[jvoight]

Yes, it certainly would!! Can I look at an example?

You can read off the central character from the Brandt matrices, but I don't immediately see how to do it from the eigenvalues themselves. Which means this could be some work.

[jvoight]

Actually, I take it back: when it applies, the Eichler-Shimura construction says that if you have a dimension 1 newform so rational Hecke eigenvalues, then you associate an elliptic curve. This comes from taking a quotient of the Jacobian of a Shimura curve, and the central character does not figure into this. Although the Eichler-Shimura construction fails to apply to HMFs over even degree fields with squarefull level, the answer should be uniform and so won't depend on this.

[jvoight]

Update: the space of Hilbert modular forms computed using quaternionic methods is in fact a direct sum of spaces according to characters of the narrow class group. One can compute this decomposition (as mentioned above), but we did not do this when we computed forms--and it is not clear how to do this from the eigenvalues themselves.

So, in short, over a totally real field with narrow class number >1, the L-function of any Hilbert modular form that appears may be wrong. This includes a large number of fields, but it looks like this affects fewer forms than it the worst case may make it seem.

To fix this, we'll need to recompute the space and then the character. I am working now to do this, but it may take some time.

If I fail, as a backup we can restrict the database of HMFs for 1.0 to those fields with narrow class number 1. This is a fast fix (restrict output to certain fields), but it leaves us without a bunch of forms. So I'll try to just actually fix this problem.

Thanks to Lassina Dembele for talking through some of this with me.

[davidfarmer]

Worst case, don't we just need to hide the links to those L-functions?

[JohnCremona]

Do you have a list of the fields affected, so I can compare with the ones for which I had trouble finding elliptic curves? We could just delete the database entries for HMFs for those fields. I have written scripts which download the database data and also have new scripts which (re)upload it so that would be possible.

On 7 April 2016 at 03:16, jvoight notifications@github.com wrote:

Update: the space of Hilbert modular forms computed using quaternionic methods is in fact a direct sum of spaces according to characters of the narrow class group. One can compute this decomposition (as mentioned above), but we did not do this when we computed forms--and it is not clear how to do this from the eigenvalues themselves.

So, in short, over a totally real field with narrow class number >1, the L-function of any Hilbert modular form that appears may be wrong. This includes a large number of fields, but it looks like this affects fewer forms than it the worst case may make it seem.

To fix this, we'll need to recompute the space and then the character. I am working now to do this, but it may take some time.

If I fail, as a backup we can restrict the database of HMFs for 1.0 to those fields with narrow class number 1. This is a fast fix (restrict output to certain fields), but it leaves us without a bunch of forms. So I'll try to just actually fix this problem.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/396#issuecomment-206658696

[jvoight]

@JohnCremona : the field list is attached, with code to produce it at the top. hmfs_hplusgt2.txt

I think the easiest thing is to do what @davidfarmer suggests: to hide the L-function when the narrow class number of F is 1. If I'm not going to do something hacky, I think we will need to address #994 before thinking about labeling and working with characters of narrow class groups. For the moment, I plan to add the narrow class numbers to hmfs.fields and then only display an L-function friend if this narrow class number is equal to 1.

[jvoight]

See #1057. Should I have made a patch? I made a pull request instead. (If someone wants to take me to git school for doing something wrong, I'm all ears.)

If someone merges #1057, please don't close this issue, just remove the milestone. I would still like to actually address the issue with the L-function.

[jvoight]

@jwj61 notes that my change did not affect the upload script. @JohnCremona, I know you've developed something to do this, didn't see yet how it all works, but we should add a line to that script that also computes and adds the narrow class number.

[jwj61]

It changes the upload script, but the new function is not used (so effectively no change).

I just looked at your database, and the data has been inserted.

I think the only thing left is to change render_hmf_webpage in lmfdb/hilbert_modular_forms/hilbert_modular_form.py to only show the L-function link when the narrow class number is 1 (if I understand what you are doing).

[jvoight]

Right. I defined a function, ran it, but it is not set to run if and when the import script runs again.

In the change I made (and you merged), it shows a link and says "L-function not available". So I think it's done.

[jwj61]

I don't see the "not available" on the beta server (I just pushed the master branch there and restarted the server). I looked at the form corresponding to the note at the top of this issue, and over Q(sqrt 3), which also has narrow class number >1. Both times I had an L-function friend which took me to the L-function page.

[jvoight]

That's because I'm an idiot--I didn't "git add" the right file. Pull request is in #1064.

Sorry guys.

[JohnCremona]

OK, good. The only thing to be aware of when re-uploading is that where you originally only had one of each Galois orbit of conjugate levels, we added the conjugates. So if you now replace the forms for the original orbit representative only, that will result in inconsistencies. To avoid this will require some care -- unless your new data covers all conjugate levels in which case there would be no problem. A separate one-off script to delete the squareful levels might be a good idea but that would of course leave the database with "missing" entries for a while.

John

On 19 April 2016 at 03:25, jvoight notifications@github.com wrote:

Hi @JohnCremona https://github.com/JohnCremona ,

I'm almost done (fingers crossed) recomputing the HMF data for the affected forms.

I found in total 620 (Galois conjugacy classes of) forms, occurring over the fields '3.3.49.1', '3.3.81.1', '3.3.169.1', '3.3.361.1', '3.3.961.1', '3.3.1369.1', '3.3.1849.1', '5.5.14641.1, that are Galois, odd degree, and with forms of squarefull level: these are the ones where in running the indefinite method and recombining with the definite method, some issue might have arisen. I think I isolated what the problem was--an annoying problem with code using Automorphisms() and rewriting primes--but I am not 100% sure about this (it's been too long, and I don't exactly remember what scripts I ran as these last minute patches).

Unfortunately, this does not give any insight into your missing elliptic curves, so at some point (for LMFDB v1.1?), we should dig into this more seriously.

For v2.0, I'd like to do HMF with higher (nonparallel) weight, and character, modelling after a stable version of the classical modular forms--this will come after some new algorithms. This promises some other mathematical rewards, and I have some other optimizations in mind. For that reason, I don't want to recompute the entire existing HMF dataset as it stands, or try to extend it using the existing implementation. (As far as I checked, I did not see any other problems, but of course I can't be sure. First, I do believe we will have more detection/certification of forms when we have the L-functions precomputed. Second, I'm also working with Sam and Ben to play with q-expansions of Hilbert modular forms, in which case this would give another way to sanity check the forms.)

Anyway, rerunning makes files like the one attached, similar to old data files. For safety, I'm computing all conjugate levels too, to match. data_3_00169_recomputed_squarefull.txt https://github.com/LMFDB/lmfdb/files/225123/data_3_00169_recomputed_squarefull.txt

Once everything is done, I will ensure that the eigenvalues are permutation of the old eigenvalues, so the alphabet labels remain the same. (For my own sanity, I will also probably replace matching lines in my text files and make a v1.2 of them.)

So my question to you: after that, may I use my old upload script to replace them in the mongodb? I think that should cause minimal damage--and I'll be careful as I go-=but I wanted to make sure I'm not overwriting something that you've done.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/396#issuecomment-211696343

[jvoight]

Sorry, John, I moved my comment from this issue to #444 where it belongs. I'll reply there. JV

[JohnCremona]

What happened with this? The graph at http://www.lmfdb.org/L/ModularForm/GL2/TotallyReal/2.2.104.1/holomorphic/2.2.104.1-5.2-c/0/0/ looks very weird indeed. But there is no link to here (now) from the HMF so perhaps it is OK to have this URL apparently working but not really?

[edgarcosta]

That L-function was disabled as its conductor is larger than 40000 (an arbitrary cutoff that was decided earlier on). I think it is okay to have the URL working as long nothing links to it.

[JohnCremona]

Thanks. OK to close this then?

[edgarcosta]

I think the obvious issued has been addressed by the line: https://github.com/LMFDB/lmfdb/blob/master/lmfdb/hilbert_modular_forms/hilbert_modular_form.py#L367

I'm not sure about the underlying issue. I will let @jvoight chime in.

[jvoight]

We still have not addressed the issue that certain HMFs in the database have nontrivial central character. Lassina is coming to Dartmouth in April and we will robustly tackle it then. As y'all noticed, we changed the friends to ensure that a user who is clicking can never navigate to a wrong L-function. That being said, we need some issue that tracks this issue with incorrect central character until it is resolved! I just looked at the list and I think this is the best fit, so I suggest that we leave this open for the moment.

[AndrewVSutherland]

@jvoight Any update on this? I note that this issue is now the oldest (3.5+ years) open issue we are tracking that is not a feature request.

[jvoight]

Lassina did not finish this while he was at Dartmouth, so this issue should remain open: we should compute the central character of the HMFs in the database. This is not something that can be done quickly. I've asked Lassina for the code he wrote, but he left and hasn't gotten back to me.

FWIW, I do not think there is anything incorrectly displayed, just some forms over fields with narrow class number > 1 that need this asterisk. As Edgar pointed out, the corresponding L-functions are not available.

To be very honest, I would rather kick off an HMFs-LMFDB 2.0 database in 2020, modelled after all the important things we learned in making CMFs-LMFDB 2.0, and including more general character and higher weight. We can address this issue at that time.

If you're just carpet sweeping, you can make this ("add central character") a feature request.

[AndrewVSutherland]

@jvoight If the plan is to expand/revisit the HMF database in 2020, I see no reason to try to address this issue if a fix is not readily available (which is really what I was asking). The fact that the L-functions in question have been hidden means there really isn't an issue with the current web site, just additional data that we wish we had. I will create a feature request to add central character for HMFs (and then compute L-functions for all the forms over fields with narrow class number > 1) and tag it for Release 2.0.

[jvoight]

That's right, there is no easy fix available.

I don't know if it's a "plan" to revisit HMF in 2020, but it's the right way to address this issue and #3112.

Thanks!