> < ^ From:

< ^ Subject:

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

> < [top]