search

edgarcosta / hilbertmodularforms

Mockup implementation of Hilbert Modular Forms
BSD 3-Clause "New" or "Revised" License
8 stars 15 forks source link

Access to the graded ring of modular forms #210

Open a-kulkarn opened 2 years ago

a-kulkarn commented 2 years ago

At the moment, there is an implicit notion of a graded ring of Hilbert modular forms, in that if f,g are HMFs with the same level the product f*g is interpretable by Magma. At present, there is no explicit encoding of a "GradedRing" of modular forms of level N.

The proposal discussed today is to have some functionality like

R, mp := GradedRingOfHMFs(K, N); // For realsies this time.

with R a standard RngMPol object (or quotient of this by an ideal) and mp a function sending the degree k part of R to HMFSpace(K, N, [k, k]). This map will complain if it is given an inhomogeneous element, and should have an inverse.

A non-lazy version could make use of GeneratorsAndRelations. A lazy version could be interesting to think about.

jvoight commented 2 years ago

I think this is already interesting for the case F equal to the rational numbers! We could practice with that simpler case, where DZB and I give (uniform, then more precise) bounds.

a-kulkarn commented 2 years ago

Here's an iconoclastic suggestion: How about we have a Ring Object and change things such that Parent(f) returns this graded ring object, so all modular forms of the same level and number field (but different weights) have the same parent. We could internally to the package replace Parent calls with something else (for arguments sake, Nanny) to access the HMF spaces. I wouldn't be surprised if this doesn't work for a lot of reasons, like if there are different ways to assemble HMFSpaces into graded rings, but I thought I'd throw the idea out there.

Here's what got me thinking along these lines: Today, I was trying to write an "Evaluate" function that takes a polynomial and a list of HMFs and returns an HMF. That's all well and good, except that this function has to have type signature

Evaluate(::RngMPol, ::List) -> ModFrmHilDElt

Except now, anytime someone else writes a function with the same signature, conflicts ensue. My version of the function is "duck typed", so we avoid most problems in this example, but in general it may let us replace List types in the code with SeqEnum[ModFrmHilDElt]'s.

It also means that we no longer need the proxy polynomial ring object described above, and we can just have a "GradedRingOfHMFs" as intended.

jvoight commented 2 years ago

This would take me a while to get used to. I think of a modular form as belong to its vector space of forms (with the same weight, level, and character), and I think of these spaces as the graded pieces of the graded ring of modular forms. I don't think I'm alone? I think this is a 'parent of a parent' issue.

I'm excited for our on graded rings, but I don't think we should tear up the carpet.

Won't there be other ways to solve a signature conflict like this? An easy solution here is just to have cases in the Evaluate function itself, depending on what the input is. (This isn't optimal, but it happens fairly frequently.) I'm not super worried about the overloading of this function: what is an example of a hypothetical future conflict that couldn't be resolved this way? I'm not bothered by using List instead of SeqEnum[ModFrmHilDElt]. Should I be?