galois_action on cusps has a bug and incorrect documentation II

[JohnCremona]

This is a follow-up from #13253, sicne that ticket did not completly fix the problem. To quote from a late comment there:

I was using this function recently and unfortunately the documentation makes incorrect claims for its applicability! Being based on Steven's book, it works for some congruence subgroups of level N, but not all of them.

The example I have is this. I have a subgroup of level 13, index 91, consisting of matrices in PSL(2,Z) whose mod-13 reduction lie in a subgroup of PSL(2,13) isomorphic to A4. Under the action of A4 the 84 cusps of Gamma(13) form 7 orbits of size 12 each. But the action of (t mod 13) is only well-defined for t=1,5,8,12 (i.e. the cubes mod 13). I could give examples of 2 cusps c1,c2 which are A4-equivalent but the results of c.galois_action(2,13) for c=c1,c2 are not A4-equivalent. This can be explained by looking carefully at Stevens' proof of his proposition, which relies on the field of modular functions for the group in question being generated by by functions whose Q-expansions have rational coefficients. This is true for Gamma(N), Gamma0(N), Gamma1(N), but not in general. In my case the field of coefficients required is the cubic subfield of Q(zeta13), which explains why Stevens's formula is only valid when t is a cube.

I think that the way to fix this is to change the documentation so that the function does not claim to do more than it does. A complete fix would require something really new, with input more than just the level N and an invertible residue class t mod N. I was able to work out my specific example, but a general implementation would be quite hard. [For the record, the 7 cusps consist of 2 Galois orbits, of size 3 and 4. Using Sage's function restricted to t=5 (which generates the cubes mod 13) I found a 4-cycle and 3 fixed points, including infinity, and as I already knew that infinity was in an orbit of size 3 that was sufficient!]

CC: @pjbruin

Component: modular forms

Keywords: cusps galois

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

[mstreng]

comment:1

Hi John,

Yes, you are right about that. All this assumed that the function field was generated by the field of functions with Fourier coefficients in QQ, and even used that as the definition of the rational model. So it does not directly apply to your example. However, on a quick reading, I can't find where the documentation claims that it does apply to all modular curves. In any case, you are right that a warning in the documentation is in order. Something like "This only gives well-defined cusps if the field of functions is generated by functions with rational Fourier expansions, such as for Gamma = ...."?

At the same time, maybe the output is not completely bogus even in your example. Does the following interpretation make sense?

Your curve has a model over a cubic field, and Gal(QQab / QQ) acts by sending cusps of your curve to cusps of Galois conjugates of your curve. So even though (2 mod 13)c1 is not equivalent to (2 mod 13)c2 modulo A_4, it is equivalent modulo some conjugate of A_4.

Marco

[mstreng]

comment:2

Replying to @mstreng:

equivalent modulo some conjugate of A_4.

This would be a GL_2(ZZ/13ZZ) conjugate of A_4 corresponding to a Gal =[ (ZZ/13ZZ) / cubes ] conjugate of your curve.

[JohnCremona]

comment:3

Hi Marco, I think that a warning in the documentation is needed, despite your clever way of interpreting the output in the general case as correct! Your interpretation makes perfect sense, but... In my example, just to add to possible confusion, the curve (which has genus 3) has a plane quartic model over QQ, though in a moduli-theoric sense it is defined over the field I call QQ(zeta13++), the cubic subfield of QQ(zeta13). But while there is a well-defined action of (Z/NZ)^* on cusps c in P^1(QQ) corresponding to the interpretation of c as a cusp of Gamma(N), i.e. commuting with the action of Gamma(N), it does not commute with the action of arbitrary congruence subgroups of level N.

[koffie]

comment:4

Hi, I think this error slipt in because I'm more used to thinking something that I will denote by X'(N). Namely the modular curve that parametrized Z/NZxZ/NZ immersions. The action of galois is trivial on Z/NZxZ/NZ there are no problems in this case since for a congruence subgroup Gamma \supset Gamma(N) one can define the quotient X'(N)/(Gamma/ Gamma(N)) and in this way the galois action on the cusps is compatible between all modular curves.

This X'(N) has some disadvantages, namely its not geometrically connected and hence not a model of H^/Gamma(N), but instead it's a model of several copies of H^/Gamma(N). What is used in sage is the modular curve X(N) that parametrizes mu_NxZ/NZ immersions together with some condition on the weil paring. This X(N) this will be an irreducible component of my X'(N) after base change to Q(zeta_N)

Now in sage I just didn't think about the fact that the action of GL_2(Z/NZ) cannot be defined on mu_NxZ/NZ and hence that it is not possible to define an arbitrary modular curve of level N as X(N)/(Gamma/ Gamma(N)) since this will mess up the galois action as John mentioned.

I wonder whether the condition mentioned by John that:

 The field of modular functions for the group in question is generated by functions whose Q-expansions have rational coefficients.

Is equivalent with the condition:

H/Gamma can be given a model over Q such that X(N)=H/Gamma(N) -> H/Gamma is defined over Q.

[11d1fc49-71a1-44e1-869f-76be013245a0]

comment:5

I think John's condition "the field of modular functions is generated by functions whose q-expansions have rational coefficients" is equivalent to "the subgroup of SL2( Z / N ) corresponding to Gamma is normalized by [1, 0; 0, x] for every x in (Z / N)*". This is at least something we can test for; but it is not satisfied by many interesting congruence subgroups. (I don't know about John and Barinder's example; but Elkies' level 9 subgroup, parametrizing elliptic curves with Galois representation that's surjective mod 3 but not mod 9, certainly does have a canonical model over Q compatible with its moduli interpretation, but not one which satisfies this condition).

If we want to do this properly, we should make galois_action take more data about the modular curve in its arguments, rather than trying to make the answer be valid for all modular curves simultaneously, which is impossible.

[JohnCremona]

comment:6

Perhaps we need to have some new classes defined, inheriting from the base class Cusp (which just means an element of P^1(QQ)), which refers to a specific congruence subgroup. Then some cusp functions, including equality and Galois action, could be over-ridden in that class.

Doing this properly and well would not be very easy, I think!

[pjbruin]

comment:9

It is certainly true that the Galois action depends on more than just the element of P¹(Q). In fact, it depends on a choice that is usually only made implicitly. Namely, a modular curve X_H of level n is defined by a subgroup H of GL₂(Z/*nZ). The natural field of definition of X_H is K_H = Q(ζ_n)^det H^. To get a modular curve defined over Q, we therefore need the determinant to be surjective. Let H₁ be the group of matrices of determinant 1 in H. When starting from a congruence subgroup, one gets H₁ instead of H; one needs to specify how to extend this to a subgroup H* as above.

For Γ₁(n), the H that one needs to take to get the usual modular curve X₁(n) is the subgroup of GL₂(Z/*nZ) consisting of the matrices with bottom row (0 1). In the context of embeddings of (Z/nZ)² into elliptic curves, this corresponds to marking the point of order n* which is the image of the second basis vector.

For general H, not necessarily with surjective determinant, there is an action of Gal(Q(ζ_n)/K_H) = det H on the set of cusps. The recipe for computing it is as follows, if my back-of-the-envelope calculation is correct.

Let s be in det H and let a/b be in P¹(Q). Choose a matrix g in H of determinant s^-1 in det H. Map a/b in the obvious way to a primitive column vector v over Z/*nZ. Compute w = g(sv); this is still a primitive column vector. Lift w to a primitive column vector x over Z. Finally, map x in the obvious way to an element of P¹(Q). This represents the desired cusp obtained by applying the Galois automorphism corresponding to s to the cusp a/b*.

In the case of the usual congruence subgroups, one can take g to be the diagonal matrix with (s^-1 1) on the diagonal. This is consistent with David's remark above. For a general congruence subgroup, one first has to extend its image in SL₂(Z/*nZ) to a group H as above (with appropriate image of the determinant, possibly giving a larger base field than Q). Second, one has to implement choosing the element g* as above.

To implement this in complete generality, we would have to allow the user to construct the modular group by giving a subgroup H of GL₂(Z/*n*Z), not just a congruence subgroup.

[JohnCremona]

comment:10

I think Peter's envelope calculation agrees with what I did with my level 13 example.

Whatever else we do, I think that the mathematical content of this ticket (and #13253) is rather higher than most, and at some point we ought to collectively write a full account of our conclusions, since these issues are not (as far as I know) discussed in such explicit detail in any books. Time for a Sage Cloud collaboration, perhaps?!

[pjbruin]

comment:11

Replying to @JohnCremona:

Whatever else we do, I think that the mathematical content of this ticket (and #13253) is rather higher than most, and at some point we ought to collectively write a full account of our conclusions, since these issues are not (as far as I know) discussed in such explicit detail in any books. Time for a Sage Cloud collaboration, perhaps?!

That would be a nice experiment. I have a Sage Cloud account, and searching for names of collaborators to add to a toy project that I have there seems to find all the people who have commented on this ticket.

Anybody who would be interested in participating? This won't place you under any obligations; if and how much any one of us wishes to contribute [to anything that will come out of this] can always be decided later.

[koffie]

comment:12

Feel free to add me :)

[JohnCremona]

comment:13

Replying to @koffie:

Feel free to add me :)

And me!

[ea1d0bf8-c27a-4548-8cb7-de0b1d02441a]

comment:17

is this issue fixed?

if not, is it 'mathematically wrong answer'?

[JohnCremona]

comment:18

I don't think it has been fixed. As noted above the simplest thing to do to be correct is just to change the documentation. That would be better than an undifferentiated tag saying "this function sometimes produces incorrect answers". The SageMathCloud project referred to here does exist and contains a 2 page tex document last edited 2 years ago. It does not contain a lot more than the mathematics written on this ticket, but it is easier to read being properly written.