Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ListWreathProductElement and WreathProductElementList #4410

Merged
merged 3 commits into from
Jun 16, 2021

Conversation

FriedrichRober
Copy link
Contributor

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

Copy link
Contributor

@hulpke hulpke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@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
Copy link
Contributor

hulpke commented Apr 16, 2021

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

@ssiccha
Copy link
Contributor

ssiccha commented Apr 19, 2021

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?

Copy link
Contributor

@ssiccha ssiccha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

lib/gprd.gi Outdated Show resolved Hide resolved
lib/gprd.gi Outdated Show resolved Hide resolved
lib/gprdmat.gi Outdated Show resolved Hide resolved
lib/gprdmat.gi Outdated Show resolved Hide resolved
lib/gprdperm.gi Outdated Show resolved Hide resolved
lib/gprdperm.gi Outdated Show resolved Hide resolved
lib/gprdperm.gi Show resolved Hide resolved
lib/gprdperm.gi Show resolved Hide resolved
lib/gprdperm.gi Outdated Show resolved Hide resolved
@FriedrichRober
Copy link
Contributor Author

FriedrichRober commented Apr 19, 2021

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
Copy link
Contributor Author

FriedrichRober commented Apr 20, 2021

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.

@FriedrichRober FriedrichRober force-pushed the fr/WreathProductElements branch 4 times, most recently from 55a552a to 184f0c6 Compare April 20, 2021 12:10
Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

lib/gprd.gi Outdated Show resolved Hide resolved
lib/gprd.gi Outdated Show resolved Hide resolved
lib/gprdmat.gi Show resolved Hide resolved
lib/gprdperm.gi Show resolved Hide resolved
tst/testinstall/opers/ListWreathProductElement.tst Outdated Show resolved Hide resolved
lib/gprd.gd Outdated Show resolved Hide resolved
@FriedrichRober
Copy link
Contributor Author

@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
Copy link
Member

@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) ?

lib/gprdmat.gi Outdated Show resolved Hide resolved
@FriedrichRober
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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

@fingolfin fingolfin requested a review from ssiccha June 16, 2021 12:21
Copy link
Contributor

@ssiccha ssiccha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

This is a hack taken from the recog package.
- Add `Projection` for perm wreath product in product action
- Add `Projection` for matrix wreath product
Add implementations of these operations for the following wreath products:
	- perm wreath product in imprimitive action
	- perm wreath product in product action
	- matrix wreath product
	- generic wreath product

Add documentation and tests for these operations.
@FriedrichRober
Copy link
Contributor Author

@fingolfin I rebased onto master and squashed the commits.

@fingolfin fingolfin merged commit 80a51fd into gap-system:master Jun 16, 2021
@FriedrichRober FriedrichRober deleted the fr/WreathProductElements branch September 21, 2021 15:01
@fingolfin fingolfin changed the title Components of Wreath Product Elements Components of Wreath Product Elements, add ListWreathProductElement and WreathProductElementList Aug 17, 2022
@fingolfin fingolfin changed the title Components of Wreath Product Elements, add ListWreathProductElement and WreathProductElementList Add ListWreathProductElement and WreathProductElementList Aug 17, 2022
@fingolfin fingolfin added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: library release notes: use title For PRs: the title of this PR is suitable for direct use in the release notes kind: new feature labels Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements kind: new feature release notes: use title For PRs: the title of this PR is suitable for direct use in the release notes topic: library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants