#7837: modular symbols -- change boundary space B_k when k odd to have the right
dimension
-----------------------------+----------------------------------------------
Reporter: was | Owner: craigcitro
Type: defect | Status: new
Priority: minor | Milestone: sage-4.3.1
Component: modular forms | Keywords:
Work_issues: | Author:
Upstream: N/A | Reviewer:
Merged: |
-----------------------------+----------------------------------------------
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
}}}
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.
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7837>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
