You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Siegel modular forms are a hard problem for the LMFDB and have been for years. And the gap between what we know and what we show has gotten bigger. There's several different kinds of information we can have about a form or a space and some spaces have much more of it than others, and several different kinds of form that can populate a space.
I feel there have been some efforts sitting around I don't know about and I've taken a crack at it in the past (with limited success) so maybe there is some work sitting around I don't know about. I'm opening this issue to a) volunteer to take another wack at it and b) make sure I know what we want it to look like before we get started. But now we have more data.
To start with it's worth dropping everything but k=3 paramodular forms. We can do this while not breaking navigation after a later addition: Siegel can redirect to pages for specific cases, including paramodular. The navigation hierarchy in the bar would go home -> Siegel -> Paramodular even if the left hand navigation bar goes to Paramodular. I'm sad about this but k=2 has only a few examples and the others have nothing.
Each level has a page with number of forms, nonlifts, and links to particular forms. Each type G form has a type and Hecke eignvalues/Euler factor and link to L-function when it exists. If it doesn't it should be added. Type Y or P should have link to the classical modular forms they come from. This might take some work. Coefficient fields should be linked to, this might be a bit messy. Worst case just list the forms and their Euler factors/L-functions.
If we have Fourier coefficients they should be presentable. This is only a handful of forms and really recent work! Maybe it's computable in lifts, but all we need is the DB shape to store it, and maybe not that.
Knowls need to be fixed up and edited
Once that's landed we can have a conversation about how to handle the rest. I might even start with fixing M_2(K(p)) first without a lot of niceties, and then we have a foundation for the rest of
The text was updated successfully, but these errors were encountered:
Siegel modular forms are a hard problem for the LMFDB and have been for years. And the gap between what we know and what we show has gotten bigger. There's several different kinds of information we can have about a form or a space and some spaces have much more of it than others, and several different kinds of form that can populate a space.
I feel there have been some efforts sitting around I don't know about and I've taken a crack at it in the past (with limited success) so maybe there is some work sitting around I don't know about. I'm opening this issue to a) volunteer to take another wack at it and b) make sure I know what we want it to look like before we get started. But now we have more data.
To start with it's worth dropping everything but k=3 paramodular forms. We can do this while not breaking navigation after a later addition: Siegel can redirect to pages for specific cases, including paramodular. The navigation hierarchy in the bar would go home -> Siegel -> Paramodular even if the left hand navigation bar goes to Paramodular. I'm sad about this but k=2 has only a few examples and the others have nothing.
Each level has a page with number of forms, nonlifts, and links to particular forms. Each type G form has a type and Hecke eignvalues/Euler factor and link to L-function when it exists. If it doesn't it should be added. Type Y or P should have link to the classical modular forms they come from. This might take some work. Coefficient fields should be linked to, this might be a bit messy. Worst case just list the forms and their Euler factors/L-functions.
If we have Fourier coefficients they should be presentable. This is only a handful of forms and really recent work! Maybe it's computable in lifts, but all we need is the DB shape to store it, and maybe not that.
Knowls need to be fixed up and edited
Once that's landed we can have a conversation about how to handle the rest. I might even start with fixing M_2(K(p)) first without a lot of niceties, and then we have a foundation for the rest of
The text was updated successfully, but these errors were encountered: