Opened 10 years ago
Closed 18 months ago
#7837 closed defect (wontfix)
modular symbols -- change boundary space B_k when k odd to have the right dimension
Reported by: | was | Owned by: | craigcitro |
---|---|---|---|
Priority: | minor | Milestone: | sage-duplicate/invalid/wontfix |
Component: | modular forms | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: | todo |
Description (last modified by )
The dimension is currently computed to be too big in some cases when k is odd. E.g., this B below should be reported to have dimension 2, not 3:
sage: ModularSymbols(Gamma1(4),7).boundary_map().codomain().dimension() 3 # bad
See also #6072, which deals with a similar problem for GammaH spaces.
Here's the email discussion of this:
> On Sun, 3 Jan 2010 13:51:19 -0800 (PST), Kilian: >> Hello, >> >> i have a problem with sage and modular symbols for Gamma1(4) and odd >> weight k, where the cusp 1/2 is irregular. >> >> According to Merel, there is (for k>2) an exact sequence: >> >> 0-> S_k -> M_k -> B_k -> 0 >> >> Here B_k is the boundary space and S_k is the cuspidal subspace. >> >> Let the weight k be 7. >> >> If I compute the appropriate dimensions with SAGE, I get 4,6 and 3 >> which can't be. Furthermore, computing the boundary map, gives a >> matrix which is definitely _not_ surjective. >> >> On the other hand, Merel explicitely states that the dimension of B_k >> is the number of cusps, i.e. 3, so the failure must already be in >> Merel's paper, or am I missing something? The B_k in Merel's paper has dimension 2. Merel does not state that dim(B_k) is the number of cusps in general. That's only true when the weight is even. Sage does have a very small bug, which is that it computes the correct space B_k but embeds it (trivially) in a bigger space. There is no need to do this, and I can see how it could be confusing. The correct relations are used, the correct map is computed, it's just that there are extra 0's tacked on. For example, in your example we have the following matrix for the boundary map: [-1 0 0] [ 0 -1 0] [ 0 -1 0] [ 0 -1 0] [ 0 0 0] [ 0 1 0] notice that the extra dimension -- the 0 in the last column -- isn't involved. The fix for this bug is to remove all the cusp classes that are equivalent to 0 because of the relation [Gamma(lambda u; lambda v)] ~ sign(lambda)^k[Gamma (u;v)] For example, in your example that would be the class (u;v) = (1;2). >> I assume that 4 and 6 are correct, as a comparison with the usual >> dimension tables for modular forms suggest. Yes. >> What is even more confusing is that Merel states that the isomorphism >> between the boundary space and the space B_k(Gamma) is an >> _isomorphism_, whereas in the SAGE sourcecode and in William Stein's >> book it is only stated that it's injective. Injectivity is all that is needed for the algorithm. -- William >> >> Thanks in advance, >> Kilian.
Change History (9)
comment:1 Changed 10 years ago by
- Description modified (diff)
comment:2 Changed 6 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:3 Changed 6 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:4 Changed 6 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:5 Changed 5 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:6 Changed 4 years ago by
- Stopgaps set to todo
comment:7 Changed 18 months ago by
- Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
- Status changed from new to needs_review
Fixed (and doctested) in the git branch I just uploaded at #6072. This ticket can be closed as duplicate when that gets merged.
comment:8 Changed 18 months ago by
- Status changed from needs_review to positive_review
Setting to positive_review, as #6072 now has a positive review.
comment:9 Changed 18 months ago by
- Resolution set to wontfix
- Status changed from positive_review to closed
closing positively reviewed duplicates
Note: See
TracTickets for help on using
tickets.
This has some substantial overlap with #6072, where I reported the same problem for GammaH groups. (This problem comes up much more often in the GammaH case than Gamma1, since Gamma1(N) has no irregular cusps unless N = 4.)