Add ListWreathProductElement and WreathProductElementList

[FriedrichRober]

Description

Notation

I am working on a package that aims to improve the performance of certain operations in wreath products.
Let $W = K \wr H$ be a wreath product and $H \leq \Sym(m)$. (I am not really interested in top actions that are not faithful or actions on an infinite set.)
We identify elements $w = (f, h) \in W$ by a tuple $(f_1, ..., f_m; h)$ where $f_i \in K$ is the $i$-th base component and $h \in H$ is the top component of $w$.

My Package and Computational Advantages of this Tuple Notation

This generic representation of an element can be exploited to solve the following problems (hopefully efficiently) by using a wreath cycle decomposition and breaking the problems down to the groups $K$ and $H$:

• Given $w, v \in W$, determine if $w$ and $v$ are conjugate in $W$ and if so, compute an element $a \in W$ such that $w^a = v$.
• Given $w \in W$, enumerate the conjugacy class $w^W$ and determine its size.
• Given $W$, enumerate representatives for all conjugacy classes of $W$ and determine the number of conjugacy classes of $W$.
• Given $w \in W$, enumerate (generators of) $C_W(w)$ and determine its size.
  In my package, I aim to provide implementations to solve these problems and hope that they will perform quite well in comparison with generic methods that do not exploit the wreath product structure.

Package WreathProductElements

The theory behind this will be described in a paper that is work in progress, by Alice C. Niemeyer, Sebastian Krammer, @DominikBernhardt, @FriedrichRober and @wucas.

Interface for Wreath Product Elements in GAP

For my package I need an interface that allows me to work with elements of a wreath product in this tuple notation efficiently.
Note that it is easy to access $F = (f, 1)$ and $h$ via the current interface of a wreath product, namely by h := w ^ Projection(W) and F := w * (h ^ (-1)) ^ Embedding(W, m + 1), but there is no convenient way known to me to access the components of $f$.

@hulpke suggested that this interface should be implemented on the GAP-side, which has the advantage that we could use the (undocumented) internal data stored in wreath products for the implementation. There are several ways how to realise such an interface, I include an implementation of such an interface in this pull request:

In analogy to PermList and ListPerm, I add two methods that translate between elements of wreath products in various representations to a list/tuple representation:

• WreathProductElementList
• ListWreathProductElement

In a follow-up pull request I suggest to document the record returned by the function WreathProductInfo partially and thus to provide some of the stored data that is shared by all wreath product representations to users and package authors.

I am very interested in other suggestions how such an interface can be realized and improved.

Further details

I fixed Projection for perm wreath products in product action,
but there are still other issues with Projection, which I have to investigate further.
For example Projection is not implemented yet for matrix wreath products.
I also need to add tests, where the top domain or the base domain gets compressed/renamed by calling WreathProduct, for example I observe the following behavior which is expected to result in issues with my implementation:

gap> G := WreathProduct(SymmetricGroup(3), SymmetricGroup([11,12,13,14,15]));;
gap> Image(Projection(G));
Group([ (), (), (), (), (), (), (), (), (), (), (1,2,3,4,5), (1,2) ])
gap> Source(Embedding(G, 6));
Sym( [ 11 .. 15 ] )

There are also issues where generators of wreath products are inconvenient, for example we have in the above example:

gap> GeneratorsOfGroup(G);
[ (1,2,3), (1,2), (4,5,6), (4,5), (7,8,9), (7,8), (10,11,12), (10,11), (13,14,15), (13,14),
  (1,4,7,10,13)(2,5,8,11,14)(3,6,9,12,15), (1,4)(2,5)(3,6) ]

But it is only necessary to store base generators for each orbit under the top action, so in this case
[ (1,2,3), (1,2), (1,4,7,10,13)(2,5,8,11,14)(3,6,9,12,15), (1,4)(2,5)(3,6) ] is a more convenient generating set of G.
I will try to solve these issues (maybe in a separate pull request).

Checklist for pull request reviewers

• proper formatting

If your code contains kernel C code, run clang-format on it; the
simplest way is to use git clang-format, e.g. like this (don't
forget to commit the resulting changes):

git clang-format $(git merge-base HEAD master)

• usage of relevant labels

  1. either release notes: not needed or release notes: to be added
  2. at least one of the labels bug or enhancement or new feature
  3. for changes meant to be backported to stable-4.X add the backport-to-4.X label
  4. consider adding any of the labels build system, documentation, kernel, library, tests

• runnable tests

• lines changed in commits are sufficiently covered by the tests

• adequate pull request title

• well formulated text for release notes

• relevant documentation updates

• sensible comments in the code

[hulpke]

Do you really want to have the element test x in G in ListWreathProductElement ? This requires dividing off a stabilizer chain each time. I'd expect that the test would actually be cheaper to do once one obtained the decomposition as tuple.

[FriedrichRober]

@hulpke You are right. So probably I will redo this safety check in ListWreathProductElement the following way:

First check input, but without the element test x in G
list := ListWreathProductElementOp(G, x);
Then check if list encodes an element of G
return list;

I still think that it might be useful if the method ListWreathProductElement checks if x is an element of G in some way. If the user is really sure that he doesn't need any safety check, he can still use ListWreathProductElementOp that doesn't do any checks on the input.

[hulpke]

OK. Then you might want to rename the Op operations into NC (no check)

[ssiccha]

The idea sounds good! I haven't looked at your code though.

I fixed Projection for perm wreath products in product action,
but there are still other issues with Projection, which I have to investigate further.
For example Projection is not implemented yet for matrix wreath products.

I've had a look now. It looks like you don't need the Projection function for matrix wreath products. I'd suggest to just leave that as it is. Maybe instead open issues about what you found?

[ssiccha]

I've got a few minor remarks. I've marked a few lines where it's not clear to me what they do. Could you add explanations there?

[FriedrichRober]

Ok, I implemented all changes @ssiccha suggested and I am nearly finished with the membership test idea proposed by @hulpke. Only the ProductAction case is missing, where the Projection is not optimized yet and throws an error instead of fail ifx is not an element of the wreath product G.

[FriedrichRober]

So, in my opinion the product action is constructed unintuitively. It seems to me, that the action of the top elements is renamed in reverse order via the isomorphism Sym([1, ..., m]) -> Sym((m, ..., 1]). The base elements act as expected. The action points are as expected translated via a qadic expansion.

gap> K := SymmetricGroup(3);;
gap> H := SymmetricGroup(5);;
gap> G := WreathProductProductAction(K, H);;
gap> x := (1,2) ^ Embedding(G, 1);; # corresponds to ( (1,2), (), (), (), (); () )
gap> y := (1,2) ^ Embedding(G, 6);; # corresponds to ( (), (), (), (), (); (1,2) )
gap> a := 3 ^ 0 + 1;; # corresponds to [2, 1, 1, 1, 1]
gap> b := 3 ^ 4 + 1;; # corresponds to [1, 1, 1, 1, 2]
# I expect that x acts on the first component via (1,2),
# i.e. [ p[1], p[2], ..., p[5] ] ^ x = [ p[1] ^ (1,2), p[2], ..., p[5] ]
gap> CoefficientsQadic(a ^ x - 1, 3) + 1; # corresponds to a ^ x = [1, 1, 1, 1, 1] as expected
[]
gap> CoefficientsQadic(b ^ x - 1, 3) + 1; # corresponds to b ^ x = [2, 1, 1, 1, 2], as expected
[ 2, 1, 1, 1, 2 ]
# I expect that y acts by permutation of the components,
# i.e. [ p[1], ..., p[5] ] ^ y = [ p[1 ^ (h ^ -1)], ..., p[5 ^ (h ^ -1)] ],
# but in GAP it acts on the components in reverse order,
# i.e. [ p[5], ..., p[1] ] ^ y = [ p[5 ^ (h ^ -1)], ..., p[1 ^ (h ^ -1)] ]
gap> CoefficientsQadic(a ^ y - 1, 3) + 1; # corresponds to a ^ y = [2, 1, 1, 1, 1], but expected [1, 2, 1, 1, 1] 
[ 2 ]
gap> CoefficientsQadic(b ^ y - 1, 3) + 1; # corresponds to a ^ y = [1, 1, 1, 2, 1], but expected [1, 1, 1, 1, 2] 
[ 1, 1, 1, 2 ]

I implemented a new version for computing the 'Projection' in this case. We can discuss, if the top action should be changed to something more intuitive.

[fingolfin]

Nice!

[FriedrichRober]

@fingolfin, I have added some new tests and applied all of your suggestions. I left the comments open that may require further discussion.

Do you know what to do about the failed tests in the environments, where ExtractSubMatrix is not defined?

[fingolfin]

@FriedrichRober sorry, didn't see your question before... Do the tests pass locally for you? Do they still pass after rebasing your PR on the latest master? Do they pass if GAP is loaded without packages (gap -A) ?

[FriedrichRober]

@fingolfin, the tests do not run without packages (gap -A). The reason is that ExtractSubMatrix does not have any implementation to deal with IsPlistRep if no packages are loaded.

[FriedrichRober]

@fingolfin I think the pull request is now ready.

I changed the option testMembership into testDecomposition, so it no longer tests for membership in G but for membership in the parent wreath product of G, i.e. it checks that the decomposition of the element x in the wreath product G is correct.

I would squash the commits into three commits once you are ready with the review:
commit 1: Add ExtractSubMatrix for IsPlistRep
commit 2: Adjust Projection methods for wreath products
commit 3: Add ListWreathProductElement and WreathProductElementList

[ssiccha]

My comments were adressed. I haven't been able to read the newest version, though.

[FriedrichRober]

@fingolfin I rebased onto master and squashed the commits.