On Tue, Sep 12, 2017 at 1:30 PM Maarten Derickx <[email protected]> wrote:
> > > On Monday, 11 September 2017 23:15:39 UTC+2, Kiran Kedlaya wrote: >> >> When you use the ModularForms constructor to create a space of modular >> forms, the backend computation of things like Hecke operators is carried >> out using the ModularSymbols class. Would it make sense to be able to >> provide the constructor with an optional argument specifying a different >> backend, such as one of the following? (ModularSymbols would remain as the >> default.) >> >> -- CremonaModularSymbols is a separate implementation of modular symbols >> derived from Cremona's code for tabulating modular elliptic curves. >> -- BrandtModules implements the "method of graphs" operating on ideal >> classes in a quaternionic order. >> -- Pari recently added a "method of trace formulas". >> -- Possibly coming soon: Birch's variant of the method of graphs based on >> reduction of quadratic forms (see https://trac.sagemath.org/ticket/23342 >> ). >> -- Did I miss something obvious? >> >> There are plenty of caveats here. For one, these methods don't all apply >> at the same level of generality, or offer the same feature set even in >> cases of overlapping applicability. For another, some of these methods are >> working with different constructions that produce isomorphic Hecke modules, >> but not "the same" (i.e., not canonically isomorphic) underlying spaces. >> >> Kiran >> > > Hi Kiran, > > The second issue is not an issue at all if one is solely interested in the > modular forms because how sage computes modular forms is by naturally > seeing them as the dual of the Hecke algebra. Since in all settings one has > that Hecke operators are represented by matrices, so if one fixes indices i > and j one gets an element of the dual of the Hecke algebra by sending a > matrix T to it's i,j entry. All sage does is try enough different i and j > until one has enough linearly independent modular forms. So this algorithm > works generically > That is one algorithm that I implemented in Sage for computing a basis (over QQ say) of q-expansions of cusp forms (it’s basically Merel’s algorithm from his “Universal Fourier expansions...” paper). It’s not the only algorithm, and usually not the most efficient (by far)... The main algorithm for computing q-expansions of newforms really does use several bits of unique nontrivial structure of modular symbols to make things more efficient. Due mostly to linear algebra differences — as has been pointed out ad nauseum over the last decade — the Magma implementation is often faster. Pari’s implementation is mainly for computing a basis of modular forms by combining together whatever one can get, more or less without using modular symbols. There are a lot of different problems one might want to solve involving modular forms, and “compute a basis” may or may not be an important step on the way to solving your real problem... It would probably be very, very useful to have a ton of examples illustrating how to use code to efficiently solve various types of nontrivial modular forms problems, and regularly run that code to ensure it doesn’t get way slower from one version of sage to the next... — William -- -- William Stein -- You received this message because you are subscribed to the Google Groups "sage-nt" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/sage-nt. For more options, visit https://groups.google.com/d/optout.
