Dear Gap forum,

Frank L"ubeck has sent various comments and suggestions to our
internal mailing list ``gap-trouble''. In this mail I want to provide
an answer to his item (10), which is concerned with centraliser
computations.

GAP is sometimes able to compute the centraliser in a group $G$ of an
element $g$ even if $g$ does not belong to the parent group of $G$,
but if $G$ and $g$ are both contained in some overgroup (which is not
present as a GAP group). For example, if $G$ is a permutation group
and $g$ is any permutation, then both are contained in some symmetric
group, so that it makes sense to define the centraliser

C_G(g) = { h\in G | g^h = g },

and this subgroup of $G$ could be computed by the same algorithm that
works if $g$ is an element of $G$. Unfortunately, the GAP dispatching
mechanism detects that $g$ is not an element of $G$ and delegates the
calculation to the default function

Stabilizer( G, g );

which calculates the orbit (i.e., the conjugacy class) of $g$ under
$G$ and uses Schreier's subgroup theorem to construct a generating set
for the stabiliser (i.e., the centraliser). This takes much longer
than the special function for permutation groups would take, and may
render the whole computation infeasible.

You can avoid this dispatching mechanism if you call

PermGroupOps.Centralizer( G, Group( g ) );

instead of

Centralizer( G, g );

then the permutation group function will perform the same computation
much faster. Of course this only works if $G$ is a permutation group
and $g$ a permutation.

I hope this helps,

Heiko Thei{\ss}en