> < ^ From:

> < ^ Subject:

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

> < [top]