Dear Forum,

in their recent contributions to the forum, Bruce W. Colletti and Dimitri
Pasechnik described a seemingly erroneuous behaviour of the
SemidirectProduct function.

G := SymmetricGroup(3);
f := IdentityMapping(G);
N := CyclicGroup(2);
sdp := SemidirectProduct(G,f,N);
Print("Size1 ",Size(sdp));

Print("\n\n");
for s in Elements(sdp) do Print("\n",s); od;
Print("\n\nSize2 ",Size(sdp));

The size of the group had changed from 12 to 36 during the calculation of
the elements of the semidirect product.

The reason for this is that f is supposed to be a group homomorphism from G
to H (see the GAP maunual). However, probably for speed reasons, the
authors of the GAP group library have chosen not to check wheter f is a
group homomorphism, or whether it has the right domain and codomain, and
have handed down the responsibility to ensure that the parameters are
admissible to the end user.

While one might certainly discuss if it would be preferable to either check
parameters to public funcitons, or else to issue a warning, the example
given in the GAP manual has probably contributed to this misunderstanding.

In this particular case, f is not a group homomorphism from G to N. the
strange behaviour is caused by the fact that G has, in fact, a natural
action (via the caret operator) on the generator of H, and H is tacitly
replaced by its closure under this operation.

Let me make a final technical remark: I was astonished to see that the
function GroupOps.Elements is not overlaid for semidirect products: one
should expect the elements of a semidirect product to be computed from the
elements of the top and the bottom groups.

Best regards,
Burkhard.

Miles-Receive-Header: reply