`Extensions`: problem with documentation or implementation

[ThomasBreuer]

The following happens in GAP 4.16.0 and in the master branch.

gap> G:= SymmetricGroup( 3 );;
gap> mods:= IrreducibleModules( G, GF(2) );;
gap> Extensions( G, mods[2][2] );
Error, the rewriting system must be confluent
[...]

As far as I understand, this happens because it is not obvious to which generating set of G the generators component of the module corresponds.

The chosen Extensions method is the one for pc groups (based on ExtensionSQ).
The documentation of Extensions( G, M ) does not state how G and M must be related, but the documentation belongs to the chapter "Pc Groups", and in fact the matrices in M.generators must belong to Pcgs( G ). The error disappears when this condition holds.

gap> mods[1];
[ (1,2,3), (1,2) ]
gap> GeneratorsOfGroup( G );
[ (1,2,3), (1,2) ]
gap> Pcgs( G );
Pcgs([ (2,3), (1,2,3) ])
gap> G:= GroupWithGenerators( [ (2,3), (1,2,3) ] );;
gap> mods:= IrreducibleModules( G, GF(2) );;
gap> mods[1];  # the matrices correspond to Pcgs( G )
[ (2,3), (1,2,3) ]
gap> Extensions( G, mods[2][2] );
[ <pc group of size 24 with 4 generators> ]

The situation is even more complicated:
Currently Extensions is documented only for solvable groups (since the return value is a list of pc groups).
The GAP library installs another Extensions( G, M ) method also for nonsolvable groups G, and this method expects M.generators to correspond to GeneratorsOfGroup( G ).
(This is because the method calls TwoCohomologyGeneric, which works with GeneratorsOfGroup( G ).
I had thought that TwoCohomologyGeneric is not installed as a method for TwoCohomology because the documentation for the latter explicitly states that the generators of the module must correspond to the Pcgs value of the group.
Perhaps the more general method for Extensions should better be called ExtensionsGeneric, and should not be installed as a method for Extensions.)

What would be a safe way to use the functions above?
First we call IrreducibleModules. The first return value is the generating set corresponding to the generators component of each module.
Then we want to call Extensions. If the input group is solvable and if the generators of the input module must correspond to the Pcgs value for the input group, is there a safe way to make sure that IrreducibleModules returns the modules relative to this pcgs?

[ThomasBreuer]

Perhaps @hulpke can give a hint?

[hulpke]

The reason for TwoCohomologyGeneric is that the output is fundamentally different from the documented one of TwoCohomology. For Extensions that is not the case, so one could use the same name.

The issue, I think is rather the differing conventions of how to connect group and module.

IrreducibleModules is allowed to choose its own generating set, as it sometimes makes it easier to write down the module.

What is needed mathematically is a homomorphism from G to the GL of the module. What is currently used is the "MeatAxeModule" model of using corresponding generating sets.

If that seems too fragile, I suggest we make Extensions more internal and create a new user function that takes a group and a homomorphism as arguments. (and the user would use IrreducibleRepresentations instead of IrreducibleModules)

[ThomasBreuer]

Thanks, @hulpke.
My understanding of your proposal is:

Provide Extensions( G, phi ) where phi is a group homomorphism from G (or a group such that G is a subgroup?) into a matrix group of dimension n over some finite prime field F.
This function can then create the MeatAxe module M over F that is given by the n by n matrices over F which are the images of GeneratorsOfGroup( G ) or Pcgs( G ) --the function must know which is correct-- and call Extensions( G, M ).

Change the documentation such that this new Extension is recommended, and such that warnings are added to the text for the old methods, concerning the assumptions on the arguments.
(Strictly speaking, only the Extensions( G, M ) method for pc groups G and modules M with M.generators corresponding to Pcgs( G ) is currently documented.)

The result of the new Extensions( G, phi ) are groups. In order to achieve that their generators (or pcgs?) fit to the generators (or pcgs?) of G, the code will likely create the internally used M w.r.t. these generators.
If one has already the module(s) in question (from the Atlas of Group Representations, say) in advance, then it might be cheaper to replace G by a group whose generators fit to the module(s), but in this case it is the user's responsibility to choose compatible G and M. The documentation should mention this.

If this description is o.k. then I can provide a pull request for its implementation.

[hulpke]

Thanks, @hulpke. My understanding of your proposal is:

Provide Extensions( G, phi ) where phi is a group homomorphism from G (or a group such that G is a subgroup?) into a matrix group of dimension n over some finite prime field F. This function can then create the MeatAxe module M over F that is given by the n by n matrices over F which are the images of GeneratorsOfGroup( G ) or Pcgs( G ) --the function must know which is correct-- and call Extensions( G, M ).

Yes. The only question is whether we want to use the same name.

Change the documentation such that this new Extension is recommended, and such that warnings are added to the text for the old methods, concerning the assumptions on the arguments. (Strictly speaking, only the Extensions( G, M ) method for pc groups G and modules M with M.generators corresponding to Pcgs( G ) is currently documented.)

Yes. If there is a wish to have documentation for the other use of extension, I am happy to provide it.

The result of the new Extensions( G, phi ) are groups. In order to achieve that their generators (or pcgs?) fit to the generators (or pcgs?) of G, the code will likely create the internally used M w.r.t. these generators. If one has already the module(s) in question (from the Atlas of Group Representations, say) in advance, then it might be cheaper to replace G by a group whose generators fit to the module(s), but in this case it is the user's responsibility to choose compatible G and M. The documentation should mention this.

Yes. The issue basically is what will be the cost of evaluating the group generators under the homomorphism -- I would think this will be almost neglegible compared to the cost of rebuilding the group on new generators.

Thank you!

Alexander