#6018: Confusing behaviour with Dirichlet characters
---------------------------+------------------------------------------------
Reporter: davidloeffler | Owner: craigcitro
Type: defect | Status: new
Priority: minor | Milestone: sage-4.0.1
Component: modular forms | Keywords: Dirichlet characters
---------------------------+------------------------------------------------
Funny things happen if you have two Dirichlet groups with the same modulus
and the same base ring, but different roots of unity. This can happen if
you use base_extend:
{{{
sage: G = DirichletGroup(10, QQ).base_extend(CyclotomicField(4))
sage: H = DirichletGroup(10, CyclotomicField(4))
}}}
Now G and H look pretty similar:
{{{
sage: G
Group of Dirichlet characters of modulus 10 over Cyclotomic Field of order
4 and degree 2
sage: H
Group of Dirichlet characters of modulus 10 over Cyclotomic Field of order
4 and degree 2
}}}
But they don't compare as equal and the generators of H don't live in G:
{{{
sage: G == H
False
sage: H.0 in G
False
}}}
Here G only actually contains those characters which factor through its
original base ring, namely QQ. This is probably going to be a bit
mystifying for the end-user.
Similar phenomena can make it next to impossible to do arithmetic with
characters obtained by base extension, which somehow are second-class
citizens:
{{{
sage: K5 = CyclotomicField(5); K3 = CyclotomicField(3); K30 =
CyclotomicField(30)
sage: (DirichletGroup(31, K5).0).base_extend(K30) * (DirichletGroup(31,
K3).0).base_extend(K30)
TypeError: unsupported operand parent(s) for '*':
'Group of Dirichlet characters of modulus 31 over Cyclotomic Field of
order 30 and degree 8' and
'Group of Dirichlet characters of modulus 31 over Cyclotomic Field of
order 30 and degree 8'
}}}
This is a particularly mystifying error for the uninitiated, since it's
asserting that it can't find a common parent, but the string
representations of the parents it already has are identical.
I can see a couple of solutions:
- Change base_extend for Dirichlet groups to pick a maximal order root of
unity in the new base ring, rather than just base-extending the root of
unity it already has. This is nice and transparent, but it could be slow
in some cases, and it prevents us constructing Dirichlet characters with
values in rings where the unit group isn't cyclic or we can't compute a
generator (e.g. we'd lose the ability to base extend elements of
{{{DirichletGroup(N, ZZ)}}} to {{{DirichletGroup(N, Integers(15))}}}).
- Change the {{{_repr_}}} method for Dirichlet groups so it explicitly
prints the root of unity involved. I don't like this idea much.
- Some combination of the above two, with a special class for Dirichlet
groups over domains where a unique root of unity of maximal order dividing
{{{euler_phi(N)}}} doesn't exist or can't be calculated. This might be
fiddly to write and maintain.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6018>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
