Working with finitely presented groups in GAP

517 Views Asked by At

This is more of a question specifically about how GAP handles calculations with finitely presented groups rather than about group theory.

I have several finite group presentations that I would like to do computations on using GAP. Suppose I have denoted one as G. For this example, suppose that by entering the command 'Size(G);', GAP takes approximately a minute to determine that G is of a large finite order. My understanding (please correct me if I am wrong) is that GAP determined this through a Todd-Coxeter coset enumeration of the trivial subgroup of G.

Ultimately, I have other computations to perform on G which I have been approaching by creating a coset table of G (w.r.t. a particular subgroup H, although taking H to be the trivial subgroup is fine for my purposes), but the command 'CosetTable(G,H);' takes an absurdly long time to complete (for this example, absurdly long is defined to mean longer than 30 minutes).

Is there any way to extract or directly access the coset table GAP generated for the trivial subgroup while computing 'Size(G);', or is there more going on behind the scenes that would make such a coset table useless? In particular, being able to trace the action of words in the free group on the generators of G make the output of 'CosetTable(G,H);' ideal for my research. Is this why it takes so long for GAP to generate this coset table, as it has to determine how the generators of G act on every coset of H, including when I define H to be the trivial subgroup of G?

1

There are 1 best solutions below

2
On BEST ANSWER

If you ask GAP for the Size of a finitely presented group, the system will (unless it already knows it) enumerate the cosets of a cyclic subgroup (typically generated by one generator), used (Modified Todd-Coveter) rewriting to get a 1-generator presentation for this cyclic group, and then calculates the group order as order of this subgroup * index. If the subgroup is large clearly the coset table by the trivial subgroup will take much longer than the index of the subgroup. (To decide whether this is the reason, one would need to know the presentation.)

If you want the coset table for the trivial subgroup, i.e. the regular permutation representation, and an order computation terminated, I would rather use IsomorphismPermGroup to obtain a faithful permutation representation, and then in that group call CosetTableBySubgroup(<permgroup>,Group(())).