Double cosets using ladder game

[mjrodgers]

The goal is to give a method for computing double coset representatives in Oscar using a subgroup ladder (including both up- and down-steps).

This can be a very effective method when it can be used; some issues are

1. finding a suitable subgroup ladder (indices of successive subgroups is small)
2. we need to be able to compute transverals for successive subgroups in the ladder, along with a recognition function (mapping group elements to a canonical representative of the coset).

I'm still working out some details of these methods, but the goal is to get this working for some special cases. In particular, when we can compute a ladder of Young subgroups, there are highly efficient ways to recognize in which coset a group element will lie.

A main application of this method is in the classification of combinatorial objects, so the aim is to provide some tools to facilitate this.

[ThomasBreuer]

Concerning a Young subgroup (of a symmetric group) constructed with inner_direct_product([symmetric_group(i) for i in p]):

On the Oscar side, this is just a permutation group. On the GAP side, it is a permutation group that stores in the attribute DirectProductInfo how it is composed from smaller groups.
Depending on what you are going to compute with these groups, we will need more information on the Oscar side.
And perhaps another interface for the construction of Young subgroups will make sense, the small symmetric groups that are currently first constructed on the Oscar side are not needed at all later on.

[mjrodgers]

On the Oscar side, this is just a permutation group. On the GAP side, it is a permutation group that stores in the attribute DirectProductInfo how it is composed from smaller groups. Depending on what you are going to compute with these groups, we will need more information on the Oscar side. And perhaps another interface for the construction of Young subgroups will make sense, the small symmetric groups that are currently first constructed on the Oscar side are not needed at all later on.

Hm yes, maybe another interface is good. I think I do not need more information on the Oscar side for what I will do, rather it is probably good to construct without this extra information on the GAP side.