Characteristic 0 matrix groups and nice morphisms and all that

[joschmitt]

I just tried to compute the maximal_abelian_quotient of a matrix group in characteristic 0, but this did not finish (in a few minutes). However, if I first compute the order of the group (it's 63700992, takes a few seconds) and then call maximal_abelian_quotient, the result is almost instantaneous. I have a rough idea what's going on: calling order computes an isomorphic group over a finite field and then GAP can use this "nice morphism".

What I am wondering about: Is this just a "trick" one needs to know as a user because sometimes it works and sometimes it doesn't? Or would it make sense to heuristically (?) decide to compute a nice morphism for GAP? I don't know what such a heuristic could be though.

I guess this is related to #2093 ; I don't know what the status of this is?

@fingolfin @ThomasBreuer

[fingolfin]

Ideally this should be handled more gracefully. GAP actually handles this via a "nice monomorphism" that it computes on the demand. Part of the problem in my view is that we have a kind of parallel "nice monomorphism" system in OSCAR, and GAP doesn't know about it and doesn't know how to invoke it.

I think I've proposed this somewhere in the past, but can't find it right now: we could install a GAP method NiceMonomorphism for the underlying GAP objects of those matrix groups which delegates to our code.

[ThomasBreuer]

It would be good to see the example of order 63700992.
For the moment, I take the group A12 in dimension 11 over QQ.

julia> info = all_atlas_group_infos("A12", characteristic => 0, dim => 11);

julia> G = atlas_group(info[1]);

julia> G = matrix_group(gens(G))      # create a new group that does not know more than its generators
Matrix group of degree 11
  over rational field

julia> maximal_abelian_quotient(G)   # takes forever ...

What happens here is that maximal_abelian_quotient delegates to GAP's GAP.Globals.MaximalAbelianQuotient.
This function is generic code, which first computes the derived subgroup of its argument.
GAP.Globals.DerivedSubgroup chooses a generic method.
If the group knows that it is finite (for example because the group order is known) then a better method for GAP.Globals.DerivedSubgroup is available.

This is a usual situation for groups that may be infinite, matrix groups as well as finitely presented groups:
As soon as the group knows that it is finite, better methods become available.
On the other hand, the finiteness test itself is expensive (perhaps it will not terminate), and currently GAP takes the viewpoint that the system does not automatically make a finiteness test.

In this sense, currently the use has to ask for the finiteness.
For finitely presented groups, I am not sure about a good strategy, but for matrix groups, I think that we can compute the finiteness flag before we call something that will probably benefit from it.

Concerning the relation to #2093: Meanwhile the situation is already better, I have updated the text accordingly.

[joschmitt]

My group is this:

julia> K, a = cyclotomic_field(8, "a");

julia> G = matrix_group([K[-1//2*a^2-1//2 -1//2*a^2+1//2 0 0 0 0 0 0; -1//2*a^2-1//2 1//2*a^2-1//2 0 0 0 0 0 0; 0 0 1 0 0 0 0 0; 0 0 0 1 0 0 0 0; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1],
       K[-a^2 0 0 0 0 0 0 0; 0 a^2 0 0 0 0 0 0; 0 0 1 0 0 0 0 0; 0 0 0 1 0 0 0 0; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1],
       K[0 0 -a^3 0 0 0 0 0; 0 0 0 a 0 0 0 0; a 0 0 0 0 0 0 0; 0 -a^3 0 0 0 0 0 0; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1],
       K[0 0 1 0 0 0 0 0; 0 0 0 1 0 0 0 0; 1 0 0 0 0 0 0 0; 0 1 0 0 0 0 0 0; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1],
       K[1 0 0 0 0 0 0 0; 0 1 0 0 0 0 0 0; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0; 0 0 1 0 0 0 0 0; 0 0 0 1 0 0 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1],
       K[1 0 0 0 0 0 0 0; 0 1 0 0 0 0 0 0; 0 0 1 0 0 0 0 0; 0 0 0 1 0 0 0 0; 0 0 0 0 0 0 1 0; 0 0 0 0 0 0 0 1; 0 0 0 0 1 0 0 0; 0 0 0 0 0 1 0 0]]);

julia> order(G)
63700992

(It's a normal subgroup of the wreath product of a degree 2 matrix group by $S_4$.)

[lgoettgens]

We already force a finiteness test in some cases, see e.g. #3157

[ThomasBreuer]

The point is that it is fine if a method decides to compute useful information such as whether a group is finite, but that in some situations there is no natural place to trigger such a computation before GAP's method selection decides which method gets called. The changes from #4826 (relying on gap-system/gap/pull/5970) are intended to improve this situation.