Confusing behaviour with Dirichlet characters

[loefflerd]

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.

There are 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.

• Make zeta optional (implemented in the current branch); see comment:18 for details

Depends on #18540

Component: modular forms

Keywords: Dirichlet characters, days71

Author: David Loeffler, Peter Bruin

Branch/Commit: 3b51d5d

Reviewer: Aly Deines

Issue created by migration from https://trac.sagemath.org/ticket/6018

[williamstein]

comment:1

David, I like your analysis of the situation a lot. I'm going to do what you suggest first. Regarding performance issues, I think if the user really is worried about that in some case, they can be explicit about the relevant spaces and zeta's.

[williamstein]

Attachment: trac_6018.patch.gz

[craigcitro]

comment:3

This looks like a nice clean fix -- my only worry would be that a few subtle choices cause mayhem with some random modular symbols code. William, did you run doctests on the modular/ directory?

Also, one potentially silly comment: your fix assumes that the constructor for DirichletGroup always chooses a maximal order and an appropriate zeta if one isn't given. While I can't imagine us ever changing that constructor to do anything different, should we either (1) explicitly choose the maximal order or (2) check and/or document this in some way? I think it's unlikely, but should it ever come up, a comment near that line of code pointing someone in the right direction could be a huge help ...

[loefflerd]

comment:4

I am running sage -testall on this patch at the moment.

The key question, I think, is what we want to happen in the following situation:

sage: f = DirichletGroup(17, ZZ).0
sage: f.base_extend(Integers(15))

This worked under the old approach, because the parent of the base-extended thing was the Dirichlet group of modulus 17 and zeta = ZZ(15)(-1), of order 2. But I suspect that with this patch it will fail now, with an error message about not being able to compute roots of unity mod 15.

I suggest a further modification which makes the constructor raise a more intelligent error message if the root of unity isn't specified and the base ring is one where we can't do factorisation. If the tests pass I will write such a patch, and give William's patch a positive review conditional on that.

[loefflerd]

Attachment: trac_6018-2.patch.gz

apply over previous patch

[loefflerd]

comment:5

As promised, here is a second patch. This takes a compromise approach where base_extend tries to calculate a maximal order root of unity in the new base ring if it's an integral domain, but otherwise uses the base-extension. I've added a couple of doctests, including one to illustrate the perils of the zeta_order argument.

If someone else can approve the new patch I think we're sorted.

[craigcitro]

comment:6

This looks good -- I just have two questions:

• In the last example, you show that weirdness ensues when the provided zeta doesn't have order zeta_order. Couldn't we (optionally, with a check=... parameter) check this? Having it on by default definitely seems like it'd stop users from shooting themselves in the foot.

• Is it possible for the call to base_ring(zeta) to raise an exception? If so, do we want to catch that and provide a more direct error message, or just let it go?

[loefflerd]

comment:7

The docs state several times that you don't actually need to supply zeta_order, so nobody's going to use the option in the first place unless they've got a pretty good reason to do so. I'd rather not make the code still more complicated! (Would it actually cause that much harm to get rid of the zeta_order argument entirely?)

If base_ring(zeta) raises an exception, the error message will say something like "Unable to coerce foo into bar", and it should be reasonably clear what the problem is. With these patches, the constructor will almost always be getting called without specifying zeta and zeta_order anyway.

David

[craigcitro]

comment:8

I'm a big fan of just removing the zeta_order argument -- looking at the code, there's no real reason to specify it, and it'll clean up a few statements in the constructor.