problem with IsomorphismPermGroup

[ThomasBreuer]

trafficstars

Graham Ellis has sent a bug report to GAP support.

 ┌───────┐   GAP 4.10.2 of 19-Jun-2019
 │  GAP  │   https://www.gap-system.org
 └───────┘   Architecture: x86_64-pc-linux-gnu-default64-kv3
 Configuration:  gmp 6.1.2, readline
 Loading the library and packages ...
 Packages:   GAPDoc 1.6.2, PrimGrp 3.3.2, SmallGrp 1.3, TransGrp 2.0.4
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> G:=SL(2,3);;Order(G);
24
gap> P:=Image(IsomorphismPermGroup(G));;Order(P);
48

In the current master branch, this bug may show up or not, depending on the loaded packages; without packages (via the -A option) the bug is present.

What happens when one calls IsomorphismPermGroup( SL(2,3) ) is the following.

• In GAP 4.9 and 4.10.2, the method for matrix groups (from grpmat.gi) has the highest rank. The code of this method differs in the two versions. The GAP 4.10.2 variant replaces the given group by the full GL overgroup, which results in the wrong result. The GAP 4.9 variant does not (yet) contain such a replacement, this GAP version returns a correct result.
• In the master branch, the method for niceomorphisms (from grpnice.gi) can have the highest rank, provided that some packages are loaded, and this method restricts the mapping to the given group, as required; in this case, the bug is not present.

In both cases, one gets the following in the current master branch.

gap> meth:= ApplicableMethod( IsomorphismPermGroup, [ SL(2,3) ], 0, "all" );;
gap> Set( List( meth{ [ 1, 2 ] }, f -> Size( Image( f( SL(2,3) ) ) ) ) );
[ 24, 48 ]

[hulpke]

The issue is that the homomorphism returned is defined on GL(2,3). (The idea is to avoid creating many different maps when working with subgroups).

gap> Size(Image(IsomorphismPermGroup(G),G));
24

Forcing the homomorphism to be restricted currently is costly (as it forces a re-do of computing data structres for the homomorphism).

[ThomasBreuer]

@hulpke I interpret your comment as the proposal to introduce an attribute MonomorphismPermGroup, and to recommend using this instead of IsomorphismPermGroup, at least in situations where one works with several subgroups of a group.

If an embedding into a permutation group is known for a parent group then this map can safely be set in any subgroup. And isomorphic permutation groups of the subgroups (even compatible ones) can be constructed on demand using Image( MonomorphismPermGroup( G ), G ), like in your example.

[hulpke]

@ThomasBreuer Adding another attribute resolves this problem, but there are many similar problems with (co)restricttions of homomorphisms and property testing. In the long run (and I realize that I am repeating myself and did not get to implementing this) I guess we need a separation of layers (as with matrices and abstract bases) between an object (I tend to call "mapper") that calculates images of elements, and a formal homomorphism that wraps a mapper and decorates it with domain, codomain, image etc. Then no separate attribute would be needed as forming the restriction just would be putting the same machinery into a new wrapper.