In her e-mail message of 13-Jan-93 Jane Bamblett writes
Suppose we type the following GAP commands.

gap> G := Group((1,2,3,4), (5,6,7,8));;
gap> H2 := Operation(G, [1,2,3,4,9,10]);
Group( (1,2,3,4) )
gap> f2 := OperationHomomorphism(G, H2);;
gap> Kernel(f2) = G;
true

- a bit peculiar?

Yes indeed. GAP does the following to compute the kernel of 'f2'. It
sees that 'G' has three orbits on '[1,2,3,4,9,10]', namely '[1,2,3,4]',
'[9]', and '[10]'. Thus it computes the stabilizers of 'G' on those
orbits (e.g., 'Stabilizer( G, [1,2,3,4], OnTuples )') and the kernel is
the intersection of those stabilizers. Now the stabilizers are
'Subgroup( G, [ (5,6,7,8) ] )', 'G', and 'G'. Unfortunately there is a
bug in 'PermGroupOps.Intersection' for the case that one of the operands
('H') is the parent group of the other operand ('G'). In this case it
simply wants to return 'G', but there is a typo, so it returns 'H'
instead.

This problem is already fixed in GAP 3.2. If you want to fix it in GAP
3.1, change the line 690 in file '<gap-dir>/lib/permbckt.g' from

K := ShallowCopy( H );

to read

K := ShallowCopy( G );

Jane Bamblett continues:

Perhaps wishing to compute with G having fixed points as above is being
perverse but perhaps it would be good if GAP could deal with perverse
situations like this, or at least notify the user of the possibility of
strange results. Any comments?

No, what you tried is not perverse at all. In GAP an operation must
satisfy the following conditions. The domain of operation <D> must be a
list without duplicates (it need not be a set, i.e., it need not be
sorted), the image of every point <d> in <D> under each element <g> of
the group <G> must again lie in <D>, the trivial element of <G> must
operate trivially on <D>, and for all elements <g> and <h> of <G>
'(<d>^<g>)^<h> = <d>^(<g>*<h>)'. The function that computes the image of
a point <d> in <D> under an element <g> in <G> must either be given as
optional third argument, or the standard operation '<d>^<g>' is used
(which can alternatively be specified by 'OnPoints'). Whenever those
conditions hold you can use 'Operation' and 'OperationsHomomorphism' and
the other functions described in chapter 8, no matter how may orbits or
fixpoints <G> has on <D>. I think the code is usually optimized for the
case that <G> has only one orbit and no fixpoints though. From a few
experiments it seems that <D> may even be the empty list, but I wouldn't
be willing to bet that this is always allowed.

Martin.

-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,  +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany