> < ^ From:

^ Subject:

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

> < [top]