One more problem with groups consisting of matrix objects

[ThomasBreuer]

The problem described in gap-packages/recog#472 is as follows:

The PreImagesRepresentative method from #6232 tries to construct a matrix (object) with Matrix( elm, Grep ) where elm is a list that describes the entries of the result, and Grep is a representative of the Source of the homomorphism in question.
The idea is that the BaseDomain and ConstructingFilter of the result are given by Grep. This is fine as long as Grep is not a list-of-list matrix. However, if Grep is a list of lists and for example the identity element of the group then BaseDomain( Grep ) is too small and we get an error. (There are quite a few tests for this situation, apparently it is not easy to run into this problem.)

The lesson is:
If we want to have common PreImagesRepresentative code for homomorphisms from matrix groups that consist of proper matrix objects of list-of-list matrices then we cannot use Matrix( elm, Grep ).
We have to prescribe the right ConstructingFilter (for that, Grep is o.k.) and the right BaseDomain. The latter is the common BaseDomain of the matrix group. In the case of groups of list-of-list matrices, we can take FieldOfMatrixGroup instead of using Grep, but in the case of proper matrix objects, FieldOfMatrixGroup may be too small, see #6359.

[fingolfin]

I think we could at least try to fix some of this for matrix groups consisting of list-of-list matrices (although it will be an uphill battle) if we respect a couple things:

First off, we need to ensure all elements of the matrix group G agree in their representation (so e.g. they are all compressed matrices over GF(9); or all plist-of-plist matrices; etc.); not a mix over different fields. Alas, I believe at least is already the case when using Group, though not in the best way perhaps, as it relies on ImmutableMatrix(f,i) which has its own share of issues:

InstallMethod( GroupWithGenerators,
    "list of matrices",
    [ IsFFECollCollColl ],
#T ???
function( gens )
local G,f;

  if not IsFinite(gens) then TryNextMethod(); fi;

  f:=DefaultScalarDomainOfMatrixList(gens);
  gens:=List(gens,i->ImmutableMatrix(f,i));

  G:=MakeGroupyObj(FamilyObj(gens), IsGroup and IsFinite, gens,false);

  if IsField(f) then SetDefaultFieldOfMatrixGroup(G,f);fi;

  return G;
end );

But this is not enough when also dealing with subgroups. We need a way such that e.g. a "trivial subgroup of GL(2,9)" remembers the field GF(9).

Neither DefaultFieldOfMatrixGroup nor FieldOfMatrixGroup can do this. @ThomasBreuer already suggested elsewhere that we should perhaps add BaseDomain for matrix groups -- I'd support that. For matrix groups over MatrixObj, it would be easy enough to infer at creation time.

But in general, there should also be a matrix group "constructor" that allows specifying this (instead of inferring it at runtime). E.g. we could add MatrixGroup([basedomain,] listOfMatricesOrMatObj[, idMat]) (see also gap-packages/ClassicalMaximals#62).

And ideally anything that constructs subgroups would also automatically set this correctly. This is easy for code using the Subgroup function (assuming we modify it to do the right thing). But I am afraid a lot of GAP code constructs subgroups by simply passing generators to Group... we can try to convert more places to use Subgroup, but in general only using MatrixObj will avoid all the pitfalls (or doing what we do in the recog and ClassicalMaximals packages: we pass not just a group around, but also a field, and make sure to keep passing that one also when going to subgroups etc. -- very cumbersome).

Still, we should at least prepare the foundations for this, and see how far we can take it. So, there are several actionable items, closely linked together:

1. add MatrixGroup([basedomain,] listOfMatricesOrMatObj[, idMat]) function as sketched above
   • should there also be MatrixGroupByGenerators and MatrixGroupWithGenerators?!
2. define BaseDomain for matrix groups
   • and set it in MatrixGroup, and also in Group when the generators are matobj
   • I would not set it in Group if the generators are matrices (that allows doing SetBaseDomain on the group generated this way)
3. teach Subgroup to transfer BaseDomain if set
4. go through functions like SylowSubgroup, Center, etc. etc. and ensure they use Subgroup
   • I just noticed that SubgroupMethodByNiceMonomorphism for example does not seem to do that

[ThomasBreuer]

A MatrixGroup function for GAP (ignoring the global function in the ClassicalMaximals package) would then mean:
Take a ring R and a list of matrices (and optionally an identity element), create a group with BaseDomain value R, with generators corresponding to the given matrices but all with BaseDomain value R.
The ConstructingFilter of the generators of the group must be the same for all generators, is it the same as the ConstructingFilter of the given matrices, or is this just the default, and we can specify this filter as an argument of MatrixGroup?

In order to make sure that the right BaseDomain is set in all subgroups, I think this should work automatically if the generators (and the identity element) of the group one starts with have the right BaseDomain. The critical situation is the creation of matrices. As long as this happens via multiplications, conjugations, etc., this should be fine (throw an error if the operands do not fit together). So the really critical situation is where a matrix arises in another way (for example as image or preimage under a map) and has to be turned into a group element, using the common ConstructingFilter and BaseDomain of the group.

Concerning SubgroupMethodByNiceMonomorphism: I think the idea is to create a subgroup that is defined as the preimage under the monomorphism of some group in the image of the monomorphism, in particular without writing down generators -- the generators are then created on demand via the monomorphism (PreImagesRepresentative does this, this was the starting point of this issue). The function Subgroup is not suitable for that.