-
Notifications
You must be signed in to change notification settings - Fork 1
Warwick workshop June 2017
Blackboard, Monday morning: picture
Projects for the June Warwick meeting:
The issue is here: #1656
The main issue is to have "no gaps".
First step: write a short script first to see the scope of the problem and the sizes of the gaps.
Probably we just delete Hecke eigenvalues after any gap. (I don't think we can always guarantee that there will be as many Hecke eigenvalues as primes, as the list of primes may increase; but they should be complete up to a specified point.) But if this is a drastic action, the spaces should be recomputed.
The issues are here: #418 #414
First step: We need mathematical input from Andy: how many Dirichlet coefficients are needed (for reasonable precision in the zeros, to make them similarish enough to the other L-functions).
I think we should start with the HMFs over real quadratic fields not coming from elliptic curves (and with trivial character). In this case, there are already a lot of a_pp's. We can always compute more.
We have an undergrad, John Martin, who is precomputing L-functions for elliptic curves over real quadratic fields (where it's easy to get more coefficients) using Booker's code (which we barely understand). We'll have that data before Warwick, maybe already in beta; but we'd also like to know if we can claim that what we computed is rigorous.
The issue is here: #396 The forms coming out of the function HilbertCuspForms() do not necessarily have trivial central character; rather, they may have a character coming from the narrow class group of the base field.
Here's an example to see that something is wrong: http://beta.lmfdb.org/L/ModularForm/GL2/TotallyReal/2.2.104.1/holomorphic/2.2.104.1-5.2-c/0/0/ It says that the sign of the functional equation does not have absolute value 1! So wrong.
First step: Edgar, Naomi, and I are meeting on Friday to discuss the "diamond" operators that compute the action of the narrow class group, and to write this up coherently. I've worked out some of this with Lassina already.
We'll see then what the next course of action should be. Probably we want to only show the HMFs with trivial character, since otherwise we have to display this character, and it opens an enormous issue of labelling and begs the question why we don't have other characters.
First step: I need to coordinate with y'all about the status of the elliptic curves and which ones are still missing. I would like to identify the scope of the problem, which I thought I had identified and resolved but must have been mistaken as I thought the issue was restricted to odd degree fields.
At https://github.com/JohnCremona/sorting you can see a scheme for labelling ideals in any number field in a consistent way, with implementations in Sage, Magma and Pari/GP by John Cremona, Andrew Sutherland and Aurel Page respectively.
At https://github.com/JohnCremona/ecnf-data/blob/master/curve_search.txt you can see a log of my elliptic curve searching, still working on some of the sextic fields (scroll to near the bottom). Look at the list of commits to see how hard I have been working ;)
John Cremona already has lists of weight 2 cuspidal Bianchi newforms over Euclidean imaginary quadratic fields (IQFs) with rational Hecke eigenvalues (up to some large level bound: see https://github.com/JohnCremona/bianchi-data). We could start by putting these in. The natural next step would be to first extend to cover all newforms and then to higher weights. We could link to elliptic curves over IQFs (they are already in) and the upcoming genus 2 curves over IQFs (see below).
A simple abelian surface over an imaginary quadratic field (IQF) F can be modular by a Bianchi modular form over F if it is of GL(2)-type or QM-type with all endomorphisms already defined over F. Ciaran has been compiling lists of such abelian surfaces (actually, of genus 2 curves giving such abelian surfaces). We should put these into LMFDB under the path "Varieties/Curves/Genus 2/OverNumberFields" and link them to Bianchi modular forms (see above).