Unexpected Projections in Wreath Products

[FriedrichRober]

I observed some strange behaviour when working with Wreath Products in GAP.
In particular I am interested in the information that is stored in WreathProductInfo.
I include a list of examples and would like to know if this is considered to be intended behaviour or a bug.

Observed behaviour 1

gap> W := WreathProduct(SymmetricGroup(5), SymmetricGroup([11,12,13]));
<permutation group of size 10368000 with 8 generators>
gap> Image(Projection(W));
Group([ (), (), (), (), (), (), (1,2,3), (1,2) ])
gap> WreathProductInfo(W);
rec( I := Sym( [ 11 .. 13 ] ), 
  alpha := IdentityMapping( Sym( [ 11 .. 13 ] ) ), 
  base := Group([ (1,2,3,4,5), (1,2), (6,7,8,9,10), (6,7), (11,12,13,14,15), (11,12) ]), 
  basegens := [ (1,2,3,4,5), (1,2), (6,7,8,9,10), (6,7), (11,12,13,14,15), (11,12) ], 
  components := [ [ 1 .. 5 ], [ 6 .. 10 ], [ 11 .. 15 ] ], 
  degI := 3, 
  embeddingType := <Type: (GeneralMappingsFamily, [ IsComponentObjectRep, IsAttributeStoringRep, 
      CanEasilyCompareElements, ... ]), data: fail,>,
  embeddings := [  ],
  groups := [ Sym( [ 1 .. 5 ] ), Sym( [ 11 .. 13 ] ) ], 
  hgens := [ (1,6,11)(2,7,12)(3,8,13)(4,9,14)(5,10,15), (1,6)(2,7)(3,8)(4,9)(5,10) ],
  permimpr := true, 
  perms := [ (), (1,6)(2,7)(3,8)(4,9)(5,10), (1,11)(2,12)(3,13)(4,14)(5,15) ],
  projection := <action epimorphism> )

Expected behaviour 1

It makes sense, that GAP renames the points for the action of the top group,
but it seems that the WreathProductInfo does not store how this renaming was carried out.
For example the entry groups stores the top group as Sym( [ 11 .. 13 ]),
but the projection maps to Sym([1 .. 3]).

Observed behaviour 2

gap> gens1 := [(11,12,13), (11,12)];;
gap> gens2 := [(1,2,3), (1,2)];;
gap> hom := GroupHomomorphismByImages(Group(gens1), Group(gens2), gens1, gens2);;
gap> W := WreathProduct(SymmetricGroup(5), Source(hom), hom);
<permutation group of size 10368000 with 8 generators>
gap>  GeneratorsOfGroup(Image(Projection(W)));
[ (), (), (), (), (), (), (11,12,13), (11,12) ]
gap> WreathProductInfo(W);
rec( I := Group([ (1,2,3), (1,2) ]),
  alpha := [ (11,12,13), (11,12) ] -> [ (1,2,3), (1,2) ], 
  base := Group([ (1,2,3,4,5), (1,2), (6,7,8,9,10), (6,7), (11,12,13,14,15), (11,12) ]), 
  basegens := [ (1,2,3,4,5), (1,2), (6,7,8,9,10), (6,7), (11,12,13,14,15), (11,12) ], 
  components := [ [ 1 .. 5 ], [ 6 .. 10 ], [ 11 .. 15 ] ],
  degI := 3, 
  embeddingType := <Type: (GeneralMappingsFamily, [ IsComponentObjectRep, IsAttributeStoringRep, 
      CanEasilyCompareElements, ... ]), data: fail,>,
  embeddings := [  ],
  groups := [ Sym( [ 1 .. 5 ] ), Group([ (11,12,13), (11,12) ]) ], 
  hgens := [ (1,6,11)(2,7,12)(3,8,13)(4,9,14)(5,10,15), (1,6)(2,7)(3,8)(4,9)(5,10) ],
  permimpr := false, 
  perms := [ (), (1,6)(2,7)(3,8)(4,9)(5,10), (1,11)(2,12)(3,13)(4,14)(5,15) ], 
  projection := [ (1,2,3,4,5), (1,2), (6,7,8,9,10), (6,7), (11,12,13,14,15), (11,12), (1,6,11)(2,7,12)(3,8,13)(4,9,14)(5,10,15), 
      (1,6)(2,7)(3,8)(4,9)(5,10) ] -> [ (), (), (), (), (), (), (11,12,13), (11,12) ] )

Expected behaviour 2

I would have expected that the entry permimpr would be true, but it is set to false.
Here the renaming is stored properly in the entry alpha, i.e. the homomorphism hom,
and the projection maps to the top group stored in groups.

[fingolfin]

Re expected behaviour 1:

One could argue whether this is a bug or a feature; one could certainly argue that the code is fine and that the manual should be changed to make it clear that the acting group P is always rewritten such that MovedPoint(P)=[1..n]).

Alternatively, one could argue that groups which don't satisfy this should simply be rejected...

However, there are there are actually (at least) two different implementations for WreathProduct(G,H,alpha) that can be used here: one for "internal" wreath products (which is used here), and one for generic "external" wreath products. And the two disagree; the latter actually does it the way you seem to be expecting it:

gap> G:=SymmetricGroup(5); H:=SymmetricGroup([11,12,13]);
Sym( [ 1 .. 5 ] )
Sym( [ 11 .. 13 ] )
gap> alpha:=IdentityMapping(H);;
gap> f2:=ApplicableMethod(WreathProduct,[G,H,alpha],0,2);
function( G, H, alpha ) ... end
gap> W2:=f2(G,H,alpha);
<group of size 10368000 with 4 generators>
gap> W2.1;
WreathProductElement((1,2,3,4,5),(),(),())
gap> W2.2;
WreathProductElement((1,2),(),(),())
gap> W2.3;
WreathProductElement((),(),(),(1,2,3))
gap> W2.4;
WreathProductElement((),(),(),(1,2))
gap> Image(Projection(W2));
Group([ (), (), (11,12,13), (11,12) ])

In any case, note that WreathProductInfo and also its memberalpha are undocumented.

Also note that this information is stored, via Embedding(W,4).

gap> Source(Embedding(W,1));
Sym( [ 1 .. 5 ] )
gap> Source(Embedding(W,2));
Sym( [ 1 .. 5 ] )
gap> Source(Embedding(W,3));
Sym( [ 1 .. 5 ] )
gap> Source(Embedding(W,4));
Sym( [ 11 .. 13 ] )

If you really want the projection to go into the "original" group, you can do this:

gap> emb*proj;
[ (11,12,13), (11,12) ] -> [ (1,2,3), (1,2) ]
gap> proj2:=proj*InverseGeneralMapping(emb*proj);
CompositionMapping( [ (1,2,3), (1,2) ] -> [ (11,12,13), (11,12) ], <action epimorphism> )
gap> x:=Random(W);
(1,12,4,11,3,13)(2,14,5,15)(6,10,9,8)
gap> Image(proj, x);
(1,3)
gap> Image(proj2, x);
(11,13)

[fingolfin]

As to "Expected behaviour 2": again, WreathProductInfo is completely undocumented, so I don't think it is wise to expect anything about it...

[FriedrichRober]

@fingolfin thanks for your answers.
Indeed, the reason for my question is that I want to compute an isomorphism from the internal wreath product to the external one in GAP, since I want to exploit the element decompositions of the form (g_1, ..., g_m; pi) of the external representation.
But since the behavior of WreathProductInfo is undocumented, I am sometimes a little bit confused if the output is expected to be that way, since to me it seems in some cases to be inconsistent.

[hulpke]

I consider the data in XXProductInfo as internal to the routines with no promises about external use. What do you mean by "internal" and "external" wreath product? Are they both constructed in GAP using WreathProduct, or is one a decomposition of an existing group?

The cleanest way is probably to use Embedding(prod,nr) rather than the emb edding information in the Info record.

[FriedrichRober]

gap> G := WreathProduct(SymmetricGroup(5),SymmetricGroup(3));
<permutation group of size 10368000 with 8 generators>
gap> x := GeneratorsOfGroup(G)[1];
(1,2,3,4,5)
K := Image(IsomorphismFpGroup(SymmetricGroup(5)));
<fp group of size 120 on the generators [ S_5.1, S_5.2, S_5.3, S_5.4 ]>
gap> G := WreathProduct(K,SymmetricGroup(3));
<group of size 10368000 with 6 generators>
gap> x := GeneratorsOfGroup(G)[1];
WreathProductElement(S_5.1,<identity ...>,<identity ...>,())
gap> x![1];
S_5.1
gap> x![2];
<identity ...>
gap> x![3];
<identity ...>
gap> x![4];
()

The first WreathProduct is what I referred to as "internal" and the second one is "external",
where elements are encoded as (g_1, ..., g_m; pi). The "external" one is the representation that I want to exploit,
so I need a fast way to translate between internal and external one.

[FriedrichRober]

@hulpke, why should I not use WreathProductInfo?
As far as I see, Embedding and Projection are created using the data provided in WreathProductInfo.
Why should I not directly use the data in WreathProductInfo for example the entry perms to recover the original naming of the base elements?

[hulpke]

@FriedrichRober

why should I not use WreathProductInfo?

Because it is not part of the documented interface.

As far as I see, Embedding and Projection are created using the data provided in WreathProductInfo.

Yes. But the data store in WreathProductInfo is not documented and what is stored, how, might make internal case distinctions.

Why should I not directly use the data in WreathProductInfo for example the entry perms to recover the original naming of the base elements?

The reason for an API (that is documented interface routines) is exactly to separate the internal data structures of an object from its access (and to allow for later changes to the code of this object without breaking other code that accesses it).
It is the same issue as why to use standardized plugs -- you could just connect cables directly for your special purpose.

Code that deliberately avoids documented interfaces is typically the one that breaks most easily.

The homomorphisms (embeddings, projections) are the proper mathematical objects to build a connection between different representations. They are documented and are promised to work. I would be surprised, if performance was an issue (if it is, let me know).

[FriedrichRober]

@hulpke thanks for your answer.
Indeed, performance was my biggest concern and thus I thought that I would need to use GAP internal code to get as fast as possible and wanted to avoid using InverseGeneralMapping. But I understand that such code would be unstable and could break on a GAP update, thus I will try to avoid using WreathProductInfo and see how fast I can get.

[FriedrichRober]

gap> G := WreathProduct(SymmetricGroup(5), SymmetricGroup([11,12,13]));
<permutation group of size 10368000 with 8 generators>
gap> emb := Embedding(G,4);
[ (11,12,13), (11,12) ] -> [ (1,6,11)(2,7,12)(3,8,13)(4,9,14)(5,10,15), (1,6)(2,7)(3,8)(4,9)(5,10) ]
gap> proj := Projection(G);
<action epimorphism>
gap> Image(proj);
Group([ (), (), (), (), (), (), (1,2,3), (1,2) ])
gap> Image(proj) = Source(emb);
false

I would expect that the source of emb is equal to the image of proj,
since the documentation of WreathProduct speaks of the same group P for Embedding and Projection.
I would even expect that we would always have (x ^ emb) ^ proj = x.

[hulpke]

This is the awkward (and probably not tested) case of the second group not acting on 1..n. In this case it is ambiguous what the permutation degree is supposed to be, though it seems the number of moved points is used. Is this the right thing to do?