This file contains the mails sent to the GAP forum in April-June 1993.

Name               Email address                           Mails    Lines
Martin Schoenert   martin@math.rwth-aachen.de                 10      303
Frank Celler       fceller@math.rwth-aachen.de                 8      218
Joachim Neubueser  neubuese@math.rwth-aachen.de                7      368
Alexander Hulpke   hulpke@abacus.concordia.ca                  5      128
Thomas Breuer      sam@math.rwth-aachen.de                     4      170
SMTP Daemon        smtp@huearn.sztaki.hu                       3      480
Goetz Pfeiffer     pfeiffer@dmi.ens.fr                         3      172
Jacob Hirbawi      jcbhrb@cerf.net                             2      118
Derek Holt         dfh@maths.warwick.ac.uk                     2      110
Jaroslav Gurican   gurican@alpha.dcs.mff.uniba.cs              2       63
Charley Wright     wright@bright.uoregon.edu                   2       60
Leonard Soicher    l.h.soicher@qmw.ac.uk                       2       48
Kay Magaard        kaym@math.wayne.edu                         2       47
Daniel Ruberman    ruberman@binah.cc.brandeis.edu              2       39
David Sibley       sibley@math.psu.edu                         2       30
Stephan Rosebrock  rosebrock@mathematik.uni-frankfurt.dbp.de   2       29
Michael Smith      smith@pell.anu.edu.au                       2       21
T. P. McDonough    tpd@aberystwyth.ac.uk                       1       75
Peter Jipsen       pjipsen@iastate.edu                         1       60
Steve Linton       slinton@math.rwth-aachen.de                 1       34
John R. Neil       neil@dehn.mth.pdx.edu                       1       34
A. E. Brouwer      aeb@win.tue.nl                              1       30
Akihiro Munemasa   munemasa@math.sci.kyushu-u.ac.jp            1       24
A. Szczepanski     aszczepa@umpa.ens-lyon.fr                   1       23
A. Caranti         caranti@volterra.cineca.it                  1       18
Lewis Stiller      stiller@blaze.cs.jhu.edu                    1       15
Chad Scherrer      scherrc@rosevc.rose-hulman.edu              1       14
Dana-Picard Noah   dana@bimacs.cs.biu.ac.il                    1       13
Frank Leonard      matleonard@bodkin.ucg.ie                    1       12
Gary K. Schwartz   schwartz@symcom.math.uiuc.edu               1       11
N. S. Mendelsohn   mendel@ccu.umanitoba.ca                     1        6
Steve Linton       sl25@cus.cam.ac.uk                          1        4

This  file is in Berkeley mail drop format, which means you can read this
file with 'mail -f <name-of-the-file>'  or 'mailx -f <name-of-the-file>'.
It is also possible however to read this file with any text editor.



From neubuese@math.rwth-aachen.de Thu Apr  1 12:33:35 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 1 Apr 93 12:33:35 +0200
Subject:    hidden treasures

Dear GAP-forum,

Thierry Dana-Picard's question provoked two immediate replies by Peter
Webb and Martin  Wursthorn  which both  stated:  I  have  written  GAP
routines  ...   .   I enjoyed seeing this, I  think it  shows that the
GAP-forum serves  its purpose. 

However  I would like  to  take  this instance  to appeal  to use  the
GAP-forum  also  for informally informing others  of  the existence of
such routines without waiting for a question. This aspect has not been
emphazised when the  function of  the GAP-forum was  explained in  the
README file with the announcement of GAP, but I think as time proceeds
there will be more  such "hidden treasures" which  might be useful for
others  as well if one knows of them.  So please tell in the GAP-forum
about routines  that  you  have  written (and hopefully are willing to
share) as well as about interesting applications.  It should  be clear
that since the GAP-forum  is  unrefereed this does in no  way conflict
with formal publications.

Joachim Neubueser



From neubuese@math.rwth-aachen.de Thu Apr  1 12:55:40 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 1 Apr 93 12:55:40 +0200
Subject:    Representation Theory in GAP

In his letter Peter Webb writes:
 
> On the topic of representation theory within GAP, I have the impression
> that this side of things has been somewhat neglected so far. The meataxe
> is implemented, but I have other goals in mind to do with creating software
> to complement this. For example, the meataxe would not be so good for
> analyzing the structure of modules for p-groups in characteristic p, but
> algorithms based upon the computation of fixed points are very effective in
> this situation. It is a long-term project for me to expand what software
> I have, and to put it into a publicly acceptable state. Right now, for
> example, it does not properly conform to the object-oriented style of GAP,
> and it is not adequately tested. At this point I would be happy to hear of
> others writing similar software (some I already know of). My general aim
> is to have a package which computes Loewy series reasonably, will extract
> a quotient in the Loewy series of a p-group as a representation of its
> normalizer in a larger group (for example), will compute relative traces
> between modules of fixed points, and such similar things.

We  agree.   While character theory (and hence ordinary representation
theory)  is  rather  well  represented in  GAP,  working with  modular
representations is not yet.  Note however that there is a link to  the
MOC system for  working  with  modular characters provided in GAP (see
section  42.46  ff,  p.679 of  the manual).  We  do  intend to  extend
facilities for working  in modular representation  theory and  we will
welcome cooperation  with others who have already implemented routines
or are implementing routines  in this  field.  We  will  contact Peter
Webb directly but  also ask others  who are  interested to contact us,
e.g.   Klaus  Lux  or  Herbert  Pahlings   (lux@math.rwth-aachen.de  ,
pahlings@math.rwth-aachen.de) and  we hope that eventually  we will be
able to provide a good package.

Joachim Neubueser



From pjipsen@iastate.edu Thu Apr  1 21:27:59 1993
From:       pjipsen@iastate.edu "Peter Jipsen"
Date:       Thu, 1 Apr 93 21:27:59 +0200
Subject:    Re: hidden treasures 

>Dear GAP-forum,
>
>Thierry Dana-Picard's question provoked two immediate replies by Peter
>Webb and Martin  Wursthorn  which both  stated:  I  have  written  GAP
>routines  ...   .   I enjoyed seeing this, I  think it  shows that the
>GAP-forum serves  its purpose. 
>
>However  I would like  to  take  this instance  to appeal  to use  the
>GAP-forum  also  for informally informing others  of  the existence of
>such routines without waiting for a question. This aspect has not been
>emphazised when the  function of  the GAP-forum was  explained in  the
>README file with the announcement of GAP, but I think as time proceeds
>there will be more  such "hidden treasures" which  might be useful for
>others  as well if one knows of them.  So please tell in the GAP-forum
>about routines  that  you  have  written (and hopefully are willing to
>share) as well as about interesting applications.  It should  be clear
>that since the GAP-forum  is  unrefereed this does in no  way conflict
>with formal publications.
>
>Joachim Neubueser
>

Not being very well-versed in group theory, I have used GAP mainly for
combinatorial problems and finite relation algebras (including
polygroups, hypergraphs and a library of small examples). I find it a
very convenient language to write little routines that test
conjectures on these finite structures, and recently I have started
putting it together as a structured domain. However there is a big
difference between code written for private research and a public
package with documentation and extensive comments.  

If other forum members are interested in the areas mentioned above, I
will gladly share what I've got. I'm certainly interested in feedback,
and on whether other GAP users are applying GAP outside group theory. 
I realise that the developers are mainly commited to supporting
algorithms related to groups, but I think they have come up with a
nice, clean development system (and are giving it away free!) that
could be a basis for several other areas of abstract algebra and
discrete mathematics. Have other users of GAP implemented algorithms
and structures for universal algebra or related areas?

At this point I am only aware of GRAPE by Leonard Soicher for
graphs. Some of my routines would greatly benefit from his approach
but at the moment small finite polygroups are represented by a domain
that contains a list of all elements (records) and an operation table.
Most simple minded algorithms in this area loop of all subsets
of elements, so the complexity very bad and they won't work for larger
structures anyway.  Relations are implemented as boolean matrices, but
it is simple to convert them to GRAPE format and then use the
interface to Brendan McKay's 'nauty' to get a more compact description
of the relation. In the near future I will also interface to some
c-code of my own, that searches for finite counter examples and 
applies some theorem proving techniques for relation algebras.

BTW does anyone know of a program that tests finitary relational
structures for isomorphism (e.g. nauty does it for binary relational
structures)?
 
Peter Jipsen



From sl25@cus.cam.ac.uk Fri Apr  2 14:09:21 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Fri, 2 Apr 93 14:09:21 +0200
Subject:    Executables and upgrade to 3r2p1

Are the executables on samson yet upgraded to 3r2p1?

	Steve



From neubuese@math.rwth-aachen.de Fri Apr  2 14:29:18 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Fri, 2 Apr 93 14:29:18 +0200
Subject:    Re: Executables and upgrade to 3r2p1

Steve Linton asks:
 
> Are the executables on samson yet upgraded to 3r2p1?
> 
> 	Steve
 
The answer is: No, not yet. But patch 1 contains only minimal 
changes in the kernel.

Joachim Neubueser (for Martin who knows such things better than I)



From rosebrock@mathematik.uni-frankfurt.dbp.de Sat Apr 10 14:12:48 1993
From:       rosebrock@mathematik.uni-frankfurt.dbp.de "Stephan Rosebrock"
Date:       Sat, 10 Apr 93 14:12:48 +0200
Subject:    maps of fin pres into symmetric groups

Dear Gap-Forum,

I don't have much experience in GAP, but I would be intersted in a
function that tests, if there is a homomorphism of a group, given as a
finite presentation, into a given symmetric or alternating group.

Stephan Rosebrock

rosebro@math.uni-frankfurt.de



From jcbhrb@cerf.net Mon Apr 12 12:17:46 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Mon, 12 Apr 93 12:17:46 +0200
Subject:    RE: maps of fin pres groups into symmetric groups

<gap-forum@samson.math.rwth-aachen.de>

Stephan Rosebrock <rosebro@math.uni-frankfurt.de> writes:

> I don't have much experience in GAP, but I would be intersted in a
> function that tests, if there is a homomorphism of a group, given as a
> finite presentation, into a given symmetric or alternating group.

I don't have much experience myself but I would like to offer a few 
suggestions since the problem of calculating Hom(G,H) for arbitrary
groups G,H is a fundementally important one. First since there is
always a trivial hom from any group to another; I will assume that the
search is for a nontrivial one or perhaps for a monic one; since Stephan
used "into a given ..." instead of "to a given ..." I will assume that 
the latter case is the one of interest.

At any rate in the case of the symmetric group there is a systematic way to
find all hom's and a way to extract the monic ones. GAP does have functions
that reduce this problem to a simple combinatorial one : first calculate the
marks of your group using TableOfMarks; then to find all hom's from your group
to the symmetric of degree n you find all possible ways you can add the rows
of the table of marks so the first entry equals n; of this list in the monic
ones n only occurs as the first entry. This is in complete ananlogy of finding
all possible representations (faithful or not) of a given group into GL(n,C) 
-- simply replace "table of marks" for "character table" and "degree" for
"dimension". In fact a generic program that takes in a matrix and finds all 
possible combination of its rows have n as the first entry and then checks if
n does not occur as another entry will work for both. It would be nice if
someone can write such a program in GAP; in the meantime for low degrees
(or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult:

Here's an example with a group defined by the presentation :

  a := AbstractGenerator("a");
  b := AbstractGenerator("b");
  c := AbstractGenerator("c");
  z := AbstractGenerator("z");
  AbsGroup1 := Group(a,b,c,z);
  AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2];

The table of marks and character tables are then :

  Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord]));
  Marks1 := MatTom( TableOfMarks( Group1 ) );
  Charachters1 := CharTable( Group1 ).irreducibles;

 Marks1;
 [ [ 24,  0, 0, 0, 0, 0, 0 ],
   [ 12, 12, 0, 0, 0, 0, 0 ], 
   [  8,  0, 2, 0, 0, 0, 0 ],
   [  6,  6, 0, 2, 0, 0, 0 ],
   [  4,  4, 1, 0, 1, 0, 0 ], 
   [  3,  3, 0, 3, 0, 3, 0 ],
   [  1,  1, 1, 1, 1, 1, 1 ] ]

All hom's from the group to Symmetric(8) for example correspond to

   [  8,  0, 2, 0, 0, 0, 0 ],         M[3]
   [  8,  8, 2, 4, 2, 2, 2 ],         M[4] + 2 M[7]
   [  8,  8, 2, 0, 2, 0, 0 ],         2 M[5] 
   [  8,  8, 2, 4, 2, 4, 1 ],         M[5] + M[6] + M[7]
   [  8,  8, 5, 4, 5, 4, 4 ],         M[5] + 4 M[7]
   [  8,  8, 2, 8, 2, 6, 8 ],         2 M[6] + 2 M[7]
   [  8,  8, 5, 8, 5, 8, 5 ],         M[6] + 5 M[7]
   [  8,  8, 8, 8, 8, 8, 8 ],         8 M[7]

so there are 8 inequivalent hom's; only the first is monic.

 Chracters1;
 [ [ 1, 1, 1, 1, 1, 1, 1 ],
  [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ], 
  [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ],
  [ 2, 0, 1, 1, -2, -1, -1 ], 
  [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ], 
  [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ],
  [ 3, -1, 0, 0, 3, 0, 0 ] ]

(I was going to do a similar calculations with the character table of the 
group for comparison but there are too many possibilities even for GL(3,C)
 -- oh well, I should have picked a simpler group!)

Hope this helps.

Jacob Hirbawi
JcbHrb@CERF.net



From smtp@huearn.sztaki.hu Mon Apr 12 12:39:31 1993
From:       smtp@huearn.sztaki.hu "SMTP Daemon"
Date:       Mon, 12 Apr 93 12:39:31 +0200
Subject:    Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 12:44:20 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 12:44:26
Subject: RE: maps of fin pres groups into symmetric groups
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 12:36:10 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12
          Apr 93 12:18:42 +0200
Date: Mon, 12 Apr 93 12:18:42 +0200
Message-ID: <9304112130.AA15242@nic.cerf.net>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: Jacob Hirbawi <jcbhrb@cerf.net>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: RE: maps of fin pres groups into symmetric groups

<gap-forum@samson.math.rwth-aachen.de>

Stephan Rosebrock <rosebro@math.uni-frankfurt.de> writes:

> I don't have much experience in GAP, but I would be intersted in a
> function that tests, if there is a homomorphism of a group, given as a
> finite presentation, into a given symmetric or alternating group.

I don't have much experience myself but I would like to offer a few
suggestions since the problem of calculating Hom(G,H) for arbitrary
groups G,H is a fundementally important one. First since there is
always a trivial hom from any group to another; I will assume that the
search is for a nontrivial one or perhaps for a monic one; since Stephan
used "into a given ..." instead of "to a given ..." I will assume that
the latter case is the one of interest.

At any rate in the case of the symmetric group there is a systematic way to
find all hom's and a way to extract the monic ones. GAP does have functions
that reduce this problem to a simple combinatorial one : first calculate the
marks of your group using TableOfMarks; then to find all hom's from your group
to the symmetric of degree n you find all possible ways you can add the rows
of the table of marks so the first entry equals n; of this list in the monic
ones n only occurs as the first entry. This is in complete ananlogy of finding
all possible representations (faithful or not) of a given group into GL(n,C)
-- simply replace "table of marks" for "character table" and "degree" for
"dimension". In fact a generic program that takes in a matrix and finds all
possible combination of its rows have n as the first entry and then checks if
n does not occur as another entry will work for both. It would be nice if
someone can write such a program in GAP; in the meantime for low degrees
(or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult:

Here's an example with a group defined by the presentation :

  a := AbstractGenerator("a");
  b := AbstractGenerator("b");
  c := AbstractGenerator("c");
  z := AbstractGenerator("z");
  AbsGroup1 := Group(a,b,c,z);
  AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2];

The table of marks and character tables are then :

  Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord]));
  Marks1 := MatTom( TableOfMarks( Group1 ) );
  Charachters1 := CharTable( Group1 ).irreducibles;

 Marks1;
 [ [ 24,  0, 0, 0, 0, 0, 0 ],
   [ 12, 12, 0, 0, 0, 0, 0 ],
   [  8,  0, 2, 0, 0, 0, 0 ],
   [  6,  6, 0, 2, 0, 0, 0 ],
   [  4,  4, 1, 0, 1, 0, 0 ],
   [  3,  3, 0, 3, 0, 3, 0 ],
   [  1,  1, 1, 1, 1, 1, 1 ] ]

All hom's from the group to Symmetric(8) for example correspond to

   [  8,  0, 2, 0, 0, 0, 0 ],         M[3]
   [  8,  8, 2, 4, 2, 2, 2 ],         M[4] + 2 M[7]
   [  8,  8, 2, 0, 2, 0, 0 ],         2 M[5]
   [  8,  8, 2, 4, 2, 4, 1 ],         M[5] + M[6] + M[7]
   [  8,  8, 5, 4, 5, 4, 4 ],         M[5] + 4 M[7]
   [  8,  8, 2, 8, 2, 6, 8 ],         2 M[6] + 2 M[7]
   [  8,  8, 5, 8, 5, 8, 5 ],         M[6] + 5 M[7]
   [  8,  8, 8, 8, 8, 8, 8 ],         8 M[7]

so there are 8 inequivalent hom's; only the first is monic.

 Chracters1;
 [ [ 1, 1, 1, 1, 1, 1, 1 ],
  [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ],
  [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ],
  [ 2, 0, 1, 1, -2, -1, -1 ],
  [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ],
  [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ],
  [ 3, -1, 0, 0, 3, 0, 0 ] ]

(I was going to do a similar calculations with the character table of the
group for comparison but there are too many possibilities even for GL(3,C)
 -- oh well, I should have picked a simpler group!)

Hope this helps.

Jacob Hirbawi
JcbHrb@CERF.net



From smtp@huearn.sztaki.hu Mon Apr 12 12:58:39 1993
From:       smtp@huearn.sztaki.hu "SMTP Daemon"
Date:       Mon, 12 Apr 93 12:58:39 +0200
Subject:    Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 13:04:26 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:04:42
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 13:04:36
Subject: Undeliverable Mail
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 12:55:14 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA21090 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:54:45 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA11211; Mon, 12 Apr 93 12:47:15 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21251; Mon, 12 Apr 93 12:48:05 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24980; Mon, 12
          Apr 93 12:39:59 +0200
Date: Mon, 12 Apr 93 12:39:59 +0200
Message-ID: <9304121039.AA24980@samson.math.rwth-aachen.de>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: <SMTP@huearn.sztaki.hu>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 12:44:20 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 12:44:26
Subject: RE: maps of fin pres groups into symmetric groups
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 12:36:10 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12
          Apr 93 12:18:42 +0200
Date: Mon, 12 Apr 93 12:18:42 +0200
Message-ID: <9304112130.AA15242@nic.cerf.net>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: Jacob Hirbawi <jcbhrb@cerf.net>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: RE: maps of fin pres groups into symmetric groups

<gap-forum@samson.math.rwth-aachen.de>

Stephan Rosebrock <rosebro@math.uni-frankfurt.de> writes:

> I don't have much experience in GAP, but I would be intersted in a
> function that tests, if there is a homomorphism of a group, given as a
> finite presentation, into a given symmetric or alternating group.

I don't have much experience myself but I would like to offer a few
suggestions since the problem of calculating Hom(G,H) for arbitrary
groups G,H is a fundementally important one. First since there is
always a trivial hom from any group to another; I will assume that the
search is for a nontrivial one or perhaps for a monic one; since Stephan
used "into a given ..." instead of "to a given ..." I will assume that
the latter case is the one of interest.

At any rate in the case of the symmetric group there is a systematic way to
find all hom's and a way to extract the monic ones. GAP does have functions
that reduce this problem to a simple combinatorial one : first calculate the
marks of your group using TableOfMarks; then to find all hom's from your group
to the symmetric of degree n you find all possible ways you can add the rows
of the table of marks so the first entry equals n; of this list in the monic
ones n only occurs as the first entry. This is in complete ananlogy of finding
all possible representations (faithful or not) of a given group into GL(n,C)
-- simply replace "table of marks" for "character table" and "degree" for
"dimension". In fact a generic program that takes in a matrix and finds all
possible combination of its rows have n as the first entry and then checks if
n does not occur as another entry will work for both. It would be nice if
someone can write such a program in GAP; in the meantime for low degrees
(or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult:

Here's an example with a group defined by the presentation :

  a := AbstractGenerator("a");
  b := AbstractGenerator("b");
  c := AbstractGenerator("c");
  z := AbstractGenerator("z");
  AbsGroup1 := Group(a,b,c,z);
  AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2];

The table of marks and character tables are then :

  Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord]));
  Marks1 := MatTom( TableOfMarks( Group1 ) );
  Charachters1 := CharTable( Group1 ).irreducibles;

 Marks1;
 [ [ 24,  0, 0, 0, 0, 0, 0 ],
   [ 12, 12, 0, 0, 0, 0, 0 ],
   [  8,  0, 2, 0, 0, 0, 0 ],
   [  6,  6, 0, 2, 0, 0, 0 ],
   [  4,  4, 1, 0, 1, 0, 0 ],
   [  3,  3, 0, 3, 0, 3, 0 ],
   [  1,  1, 1, 1, 1, 1, 1 ] ]

All hom's from the group to Symmetric(8) for example correspond to

   [  8,  0, 2, 0, 0, 0, 0 ],         M[3]
   [  8,  8, 2, 4, 2, 2, 2 ],         M[4] + 2 M[7]
   [  8,  8, 2, 0, 2, 0, 0 ],         2 M[5]
   [  8,  8, 2, 4, 2, 4, 1 ],         M[5] + M[6] + M[7]
   [  8,  8, 5, 4, 5, 4, 4 ],         M[5] + 4 M[7]
   [  8,  8, 2, 8, 2, 6, 8 ],         2 M[6] + 2 M[7]
   [  8,  8, 5, 8, 5, 8, 5 ],         M[6] + 5 M[7]
   [  8,  8, 8, 8, 8, 8, 8 ],         8 M[7]

so there are 8 inequivalent hom's; only the first is monic.

 Chracters1;
 [ [ 1, 1, 1, 1, 1, 1, 1 ],
  [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ],
  [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ],
  [ 2, 0, 1, 1, -2, -1, -1 ],
  [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ],
  [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ],
  [ 3, -1, 0, 0, 3, 0, 0 ] ]

(I was going to do a similar calculations with the character table of the
group for comparison but there are too many possibilities even for GL(3,C)
 -- oh well, I should have picked a simpler group!)

Hope this helps.

Jacob Hirbawi
JcbHrb@CERF.net



From smtp@huearn.sztaki.hu Mon Apr 12 13:09:39 1993
From:       smtp@huearn.sztaki.hu "SMTP Daemon"
Date:       Mon, 12 Apr 93 13:09:39 +0200
Subject:    Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 13:14:29 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:14:46
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 13:14:41
Subject: Undeliverable Mail
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 13:13:45 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA21365 (5.65b/CWI-2.216); Mon, 12 Apr 1993 13:13:16 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA11719; Mon, 12 Apr 93 13:06:34 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21296; Mon, 12 Apr 93 13:07:15 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA25050; Mon, 12
          Apr 93 12:59:00 +0200
Date: Mon, 12 Apr 93 12:59:00 +0200
Message-ID: <9304121059.AA25050@samson.math.rwth-aachen.de>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: <SMTP@huearn.sztaki.hu>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 13:04:26 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:04:42
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 13:04:36
Subject: Undeliverable Mail
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 12:55:14 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA21090 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:54:45 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA11211; Mon, 12 Apr 93 12:47:15 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21251; Mon, 12 Apr 93 12:48:05 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24980; Mon, 12
          Apr 93 12:39:59 +0200
Date: Mon, 12 Apr 93 12:39:59 +0200
Message-ID: <9304121039.AA24980@samson.math.rwth-aachen.de>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: <SMTP@huearn.sztaki.hu>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: Undeliverable Mail

HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s):
    <ehorvath@math.rwth-aachen.de>
HUEARN.SZTAKI.HU received negative reply:
550 <ehorvath@math.rwth-aachen.de>... User unknown

           ** Text of Mail follows **
Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP;
   Mon, 12 Apr 93 12:44:20 SET
Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31
          gmt+1
Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at
          93-04-12 12:44:26
Subject: RE: maps of fin pres groups into symmetric groups
From: gap-forum@samson.math.rwth-aachen.de
To: ehorvath@math.rwth-aachen.de
Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12
          Apr 1993 12:36:10 gmt+1
Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id
          AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200
Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de
          (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200
Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP
          (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12
          Apr 93 12:18:42 +0200
Date: Mon, 12 Apr 93 12:18:42 +0200
Message-ID: <9304112130.AA15242@nic.cerf.net>
Comment: GAP Forum
Originator: gap-forum@samson.math.rwth-aachen.de
Errors-To: martin@samson.math.rwth-aachen.de
Reply-To: <gap-forum@samson.math.rwth-aachen.de>
Sender: gap-forum@samson.math.rwth-aachen.de
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: Jacob Hirbawi <jcbhrb@cerf.net>
To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
Subject: RE: maps of fin pres groups into symmetric groups

<gap-forum@samson.math.rwth-aachen.de>

Stephan Rosebrock <rosebro@math.uni-frankfurt.de> writes:

> I don't have much experience in GAP, but I would be intersted in a
> function that tests, if there is a homomorphism of a group, given as a
> finite presentation, into a given symmetric or alternating group.

I don't have much experience myself but I would like to offer a few
suggestions since the problem of calculating Hom(G,H) for arbitrary
groups G,H is a fundementally important one. First since there is
always a trivial hom from any group to another; I will assume that the
search is for a nontrivial one or perhaps for a monic one; since Stephan
used "into a given ..." instead of "to a given ..." I will assume that
the latter case is the one of interest.

At any rate in the case of the symmetric group there is a systematic way to
find all hom's and a way to extract the monic ones. GAP does have functions
that reduce this problem to a simple combinatorial one : first calculate the
marks of your group using TableOfMarks; then to find all hom's from your group
to the symmetric of degree n you find all possible ways you can add the rows
of the table of marks so the first entry equals n; of this list in the monic
ones n only occurs as the first entry. This is in complete ananlogy of finding
all possible representations (faithful or not) of a given group into GL(n,C)
-- simply replace "table of marks" for "character table" and "degree" for
"dimension". In fact a generic program that takes in a matrix and finds all
possible combination of its rows have n as the first entry and then checks if
n does not occur as another entry will work for both. It would be nice if
someone can write such a program in GAP; in the meantime for low degrees
(or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult:

Here's an example with a group defined by the presentation :

  a := AbstractGenerator("a");
  b := AbstractGenerator("b");
  c := AbstractGenerator("c");
  z := AbstractGenerator("z");
  AbsGroup1 := Group(a,b,c,z);
  AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2];

The table of marks and character tables are then :

  Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord]));
  Marks1 := MatTom( TableOfMarks( Group1 ) );
  Charachters1 := CharTable( Group1 ).irreducibles;

 Marks1;
 [ [ 24,  0, 0, 0, 0, 0, 0 ],
   [ 12, 12, 0, 0, 0, 0, 0 ],
   [  8,  0, 2, 0, 0, 0, 0 ],
   [  6,  6, 0, 2, 0, 0, 0 ],
   [  4,  4, 1, 0, 1, 0, 0 ],
   [  3,  3, 0, 3, 0, 3, 0 ],
   [  1,  1, 1, 1, 1, 1, 1 ] ]

All hom's from the group to Symmetric(8) for example correspond to

   [  8,  0, 2, 0, 0, 0, 0 ],         M[3]
   [  8,  8, 2, 4, 2, 2, 2 ],         M[4] + 2 M[7]
   [  8,  8, 2, 0, 2, 0, 0 ],         2 M[5]
   [  8,  8, 2, 4, 2, 4, 1 ],         M[5] + M[6] + M[7]
   [  8,  8, 5, 4, 5, 4, 4 ],         M[5] + 4 M[7]
   [  8,  8, 2, 8, 2, 6, 8 ],         2 M[6] + 2 M[7]
   [  8,  8, 5, 8, 5, 8, 5 ],         M[6] + 5 M[7]
   [  8,  8, 8, 8, 8, 8, 8 ],         8 M[7]

so there are 8 inequivalent hom's; only the first is monic.

 Chracters1;
 [ [ 1, 1, 1, 1, 1, 1, 1 ],
  [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ],
  [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ],
  [ 2, 0, 1, 1, -2, -1, -1 ],
  [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ],
  [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ],
  [ 3, -1, 0, 0, 3, 0, 0 ] ]

(I was going to do a similar calculations with the character table of the
group for comparison but there are too many possibilities even for GL(3,C)
 -- oh well, I should have picked a simpler group!)

Hope this helps.

Jacob Hirbawi
JcbHrb@CERF.net



From neubuese@math.rwth-aachen.de Tue Apr 13 11:41:26 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 13 Apr 93 11:41:26 +0200
Subject:    re. maps of f.p. groups into symmetric groups

Stephan  Rosebrock asked  for a  function  that tests  if  there is  a
homomorphism of a finitely  presented group into a given symmetric (or
alternating) group. Jacob Hirbawi explained,  how to use the  table of
marks of  the finitely  presented group for  this  task. This will  of
course only work if the finitely  presented group is  also finite (and
not too big) so that GAP can calculate its table of marks, but then it
is a nice method.

However there is also a method to  find permutation representations of
a finitely presented  group of a  given  (not  too  big) degree  (i.e.
homomorhisms  into a given  symmetric group  of not too  big  degree),
which  does  not  at all assume  that the finitely presented group  is
finite, namely the so-called Low Index Method which  is implemented in
GAP  by  the  function LowIndexSubgroupsFpGroup, described in  section
22.6, page 419 of the manual of GAP 3. The practical limitation of the
degree for which  the method will work depends strongly on the  number
of generators  of  the  finitely presented group but  it  has proved a
rather useful tool for the investigation of several finitely presented
groups that appeared in the literature.  If wanted  I can provide some
references.

Joachim Neubueser



From rosebrock@mathematik.uni-frankfurt.dbp.de Wed Apr 14 11:25:08 1993
From:       rosebrock@mathematik.uni-frankfurt.dbp.de "Stephan Rosebrock"
Date:       Wed, 14 Apr 93 11:25:08 +0200
Subject:    Re:  maps of fin pres into symmetric groups

Thank you, Jacob, for your help with homomorphisms in GAP. I have
still some questions:
    You are right, I am not only interested in injective
homomorphisms, but rather all of them. My problem is that the
groups where I look for homomorphic images are not finite.
The groups are finitely generated and all relators have the
form: a b = b c for generators a,b,c. But there is certainly
still an algorithm for detecting all homomorphic images of such
a group G to a given symmetric group S: There are only finitely
many possibilities in mapping the generators of G to the
generators of S and one such possibility describes a map
entirely.
    I could not get the example Jacob sent to work, because
the group     g1    was not defined.

Stephan Rosebrock

rosebro@math.uni-frankfurt.de



From dfh@maths.warwick.ac.uk Wed Apr 14 13:46:55 1993
From:       dfh@maths.warwick.ac.uk "Derek Holt"
Date:       Wed, 14 Apr 93 13:46:55 +0200
Subject:    Re:  maps of fin pres into symmetric groups

> 
> Dear Gap-Forum,
> 
> I don't have much experience in GAP, but I would be intersted in a
> function that tests, if there is a homomorphism of a group, given as a
> finite presentation, into a given symmetric or alternating group.
> 
> Stephan Rosebrock
> 
> rosebro@math.uni-frankfurt.de
> 
> 

It seems to me that finding homomorphisms of s finitely presented group  G
into the symmetric group of degree n  is almost precisely equivalent to the
LowIndexSubgroupsFpGroup function. The call

LowIndexSubgroupsFpGroup( G, TrivialSubgroup(G), n )

returns a list of representatives of all conjugacy classes of subgroups of 
G  of index at most n.  (In general, you get all subgroups that contain the
subgroup specified by the second argument.) 

Then a conjugacy class of subgroups of  G  of index  m, corresponds to
an equivalence class of homomorphisms from  G  to a transitive subgroup of
the symmetric group of degree  m, where two homomorphisms are regarded as
equivalent if they are the same after renumbering the points being permuted.

To get the corresponding homomorphisms explicitly, I think you probably have
to use the CosetTableFpGroup (Todd-Coxeter) function.


Here is a complete example - homomorphisms of the Von Dyck 237-group into the
symmetric group of degree 10.

a := AbstractGenerator("a");
b := AbstractGenerator("b");
G237 := Group(a,b);
G237.relators := [a^2, b^3, (a*b)^7 ];
sublist := LowIndexSubgroupsFpGroup( G237, TrivialSubgroup(G237), 10 );
imlist := [];
for gp in sublist do
  ct := CosetTableFpGroup( G237, gp );
  Add( imlist, List(ct,PermList) );
od;


After this, imlist contains 4 elements, corresponding to four equivalence
classes of homomorphisms. Each of these contains the images of the
generators and their inverses under that homomorphism. (The images are
respectively the trivial group, PSL(2,7) of degree 7 twice, PSL(2,8) of
degree 9, and PSL(2,7) of degree 8.)

[ [ (), (), (), () ], 
  [ (3,4)(6,7), (3,4)(6,7), (1,2,3)(4,5,6), (1,3,2)(4,6,5) ], 
  [ (3,4)(5,6), (3,4)(5,6), (1,2,3)(4,5,7), (1,3,2)(4,7,5) ], 
  [ (2,3)(4,6)(5,7)(8,9), (2,3)(4,6)(5,7)(8,9), (1,2,4)(3,5,7)(6,8,9), 
      (1,4,2)(3,7,5)(6,9,8) ], 
  [ (1,2)(3,4)(5,6)(7,8), (1,2)(3,4)(5,6)(7,8), (2,3,5)(6,7,8), 
      (2,5,3)(6,8,7) ] ]


Derek Holt.



From martin@math.rwth-aachen.de Wed Apr 14 14:34:22 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 14 Apr 93 14:34:22 +0200
Subject:    Re: Undeliverable Mail

My apologies to everybody for the mail loop.  I think we have everything
under control again.  I am not absolutely certain, because I am still
trying to figure out what went wrong.  It seems like three or four small
problems collaborated to create this terrible mess.

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



From martin@math.rwth-aachen.de Wed Apr 14 14:36:56 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 14 Apr 93 14:36:56 +0200
Subject:    Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2)

This is to announce the availibility of the second upgrade for GAP 3.2.
This upgrade brings version 3 release 2 patchlevel 1 (V3R2P1) to version
3 release 2 patchlevel 2 (V3R2P2).  The priority of this upgrade is
medium.

The upgrade is available as file 'upg3r2p2.dif.Z' on the 'ftp' server
'samson.math.rwth-aachen.de'.  It should be available on the other 'ftp'
servers soon.  Again I do not send out this upgrade as e-mail, it is
again quite large (about 40 KBytes 'compress'-ed).

First unpack the upgrade with 'uncompress upg3r1p2.dif.Z'.  Then read the
beginning   of   the   unpacked   file  'upg3r2p2.dif',   which  contains
instructions how to apply this upgrade.

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



From fceller@math.rwth-aachen.de Wed Apr 14 16:16:39 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Wed, 14 Apr 93 16:16:39 +0200
Subject:    Re: Undeliverable Mail

Apologies to everyone who get this message twice,  there was still
a small problem in our list server,  which is now hopefully fixed.

best wishes
  Frank
-----------------------------------------------------------------------------

My apologies to everybody for the mail loop.  I think we have everything
under control again.  I am not absolutely certain, because I am still
trying to figure out what went wrong.  It seems like three or four small
problems collaborated to create this terrible mess.

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



From fceller@math.rwth-aachen.de Wed Apr 14 16:28:53 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Wed, 14 Apr 93 16:28:53 +0200
Subject:    Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2)

Apologies to everyone who get this message twice,  there was still
a small problem in our list server,  which is now hopefully fixed.

best wishes
  Frank
-----------------------------------------------------------------------------
This is to announce the availibility of the second upgrade for GAP 3.2.
This upgrade brings version 3 release 2 patchlevel 1 (V3R2P1) to version
3 release 2 patchlevel 2 (V3R2P2).  The priority of this upgrade is
medium.

The upgrade is available as file 'upg3r2p2.dif.Z' on the 'ftp' server
'samson.math.rwth-aachen.de'.  It should be available on the other 'ftp'
servers soon.  Again I do not send out this upgrade as e-mail, it is
again quite large (about 40 KBytes 'compress'-ed).

First unpack the upgrade with 'uncompress upg3r1p2.dif.Z'.  Then read the
beginning   of   the   unpacked   file  'upg3r2p2.dif',   which  contains
instructions how to apply this upgrade.

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



From sibley@math.psu.edu Wed Apr 14 17:59:26 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Wed, 14 Apr 93 17:59:26 +0200
Subject:    Re:  Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2)

Another patch?  I still haven't managed to get the first one.  There is
nothing at dimacs.rutgers.edu except old versions of GAP.  All the
files in the gap directory there have 1992 dates.

Last time I managed to connect to wuarchive.wustl.edu, about a week
ago, the first patch still was not there.  wustl is usually not
available during normal hours because its limit for anonymous logins
(175 users, which is very liberal, I think) is full.

I haven't checked the machine in California.  I think that's the one I
always have trouble with, because it generates gigantic directory
listings.

Where are people in the US or Canada getting these patches from?



From neil@dehn.mth.pdx.edu Thu Apr 15 07:36:57 1993
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Thu, 15 Apr 93 07:36:57 +0200
Subject:    Re: Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2) 

In message <9304141604.AA04962@frobenius.math.psu.edu> you write:
>Another patch?  I still haven't managed to get the first one.  There is
>nothing at dimacs.rutgers.edu except old versions of GAP.  All the
>files in the gap directory there have 1992 dates.
>
>Last time I managed to connect to wuarchive.wustl.edu, about a week
>ago, the first patch still was not there.  wustl is usually not
>available during normal hours because its limit for anonymous logins
>(175 users, which is very liberal, I think) is full.
>
>I haven't checked the machine in California.  I think that's the one I
>always have trouble with, because it generates gigantic directory
>listings.
>
>Where are people in the US or Canada getting these patches from?
>
>

In case anyone is interested, I've begun using an automatic mirroring shell
which, every night, updates my copies of everything on samson relating to
GAP.  This mirror is available via anonymous ftp from <dehn.mth.pdx.edu>.
Those in the US are welcome to use this site as an alternative source of
GAP code.

--John Neil



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Neil                                        e-mail:  neil@math.mth.pdx.edu
Director of Computer Labs and UNIX System Administrator
Portland State University Mathematics Department
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



From matleonard@bodkin.ucg.ie Mon Apr 19 18:35:39 1993
From:       matleonard@bodkin.ucg.ie "Frank Leonard"
Date:       Mon, 19 Apr 93 18:35:39 +0200
Subject:    Re: your mail

I have been attempting some constuctions of finite groups in GAP as 
defined by a presentation in abstract generators/relators. 
The problem consists of applying a certain algorithim to constuct a
group which I then attempt to identify. I also have access to the C.A. 
package CAYLEY and have re-written the algorithim for CAYLEY. I have 
found CAYLEY to be vastly superior (time wise) to GAP for this problem. 
I assume that the fact that GAP programs/functions are interpreted 
would be significant in explaining the performance discrepancies but I 
am curious if there are any other factors which might be significant. 
Can you tell me if there are any plans at present to write a compiler 
for GAP?



From neubuese@math.rwth-aachen.de Tue Apr 20 17:10:54 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 20 Apr 93 17:10:54 +0200
Subject:    Re: your mail

Frank Leonard writes:
 
> I have been attempting some constuctions of finite groups in GAP as 
> defined by a presentation in abstract generators/relators. 
> The problem consists of applying a certain algorithim to constuct a
> group which I then attempt to identify. I also have access to the C.A. 
> package CAYLEY and have re-written the algorithim for CAYLEY. I have 
> found CAYLEY to be vastly superior (time wise) to GAP for this problem. 
> I assume that the fact that GAP programs/functions are interpreted 
> would be significant in explaining the performance discrepancies but I 
> am curious if there are any other factors which might be significant. 
> Can you tell me if there are any plans at present to write a compiler 
> for GAP?

I  am sorry that we  cannot  really answer  such  an unspecified  (but
nevertheless  very  critical)  letter,  much  as  we  try to react  to
criticism  brought to our attention  in the  GAP-forum (or otherwise).
Frank Leonard  has  not  told  us what  kind of  problem he is  really
looking at, nor  which  GAP  functions he  has  used,  nor  even which
version of GAP.

There  are  of course functions  for which  the  fact  that  they  are
interpreted rather than originally written in  C  and  compiled mean a
loss of  efficiency. We  know  that this can in particular be the case
with functions which  deal  in a rather combinatorial  way  with small
data, as is the case with many functions  handling presentations.  For
this reason some of the functions for dealing  with presentations have
parts   in   the  kernel  to  circumvent   this  difficulty.   If  the
interpretation of  GAP functions was  the reason for inefficiency that
Frank Leonard has observed then  it  would be helpful for us to  know,
*how* big the loss of efficiency was  in his case for which functions,
e.g.  in comparison  with  CAYLEY.  It  is not helpful just to be told
that CAYLEY  was *vastly* superior for some function(s?)  that are not
named applying  "a certain algorithm" that he does not care to tell us
about.

It  is also likely  that for certain functions we  are using  genuinly
worse methods than CAYLEY (for others we may use better ones). Then we
want  to know even more where this  is the case in order to be able to
improve them. 

We are not only  open to  but ask  for constructive or  at least  well
specified criticism,  but I must  say that a letter like that of Frank
Leonard is not only unhelpful but rather discouraging.

Joachim Neubueser

PS. I have said already in a previous letter to the GAP-forum that the
idea to develop a compiler for  GAP is being  considered, but that, if
at  all,  a  compiler  cannot  be  expected in the  nearer foreseeable
future.



From ruberman@binah.cc.brandeis.edu Wed Apr 21 18:08:48 1993
From:       ruberman@binah.cc.brandeis.edu "Daniel Ruberman"
date:       Wed, 21 Apr 93 18:08:48 +0200
Subject:    AbelianInvariants

I am somewhat confused by the output from the AbelianInvariants function,
as applied to a finitely generated abelian group.  I am using GAP 3.2
with upgrades 1 and 2, on a DEC Ultrix workstation, if it matters.  In the
example below, I hoped to get the output [0 0], corresponding to the fact
that the abelianization of the free group on two letters ("a" and "b" below)
is Z+Z.  Have I misused the function or misinterpreted the output?

Daniel Ruberman
ruberman@binah.cc.brandeis.edu


gap> a:=AbstractGenerator("a");
a
gap> b:=AbstractGenerator("b");
b
gap> G:=Group(a,b);
Group( a, b )
gap> G.relators:=[];
[  ]
gap> H:=CommutatorFactorGroup(G);
Group( c.1, c.2 )
gap> H.relators;
[ c.1^-1*c.2^-1*c.1*c.2 ]
gap> AbelianInvariants(H);
[ 0 ]                         



From martin@math.rwth-aachen.de Wed Apr 21 19:09:32 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 21 Apr 93 19:09:32 +0200
Subject:    Re: AbelianInvariants

Daniel Ruberman writes in his e-mail message of 1993/04/21

    I am somewhat confused by the output from the AbelianInvariants function,
    as applied to a finitely generated abelian group.  I am using GAP 3.2
    with upgrades 1 and 2, on a DEC Ultrix workstation, if it matters.  In the
    example below, I hoped to get the output [0 0], corresponding to the fact
    that the abelianization of the free group on two letters ("a" and "b" below)
    is Z+Z.  Have I misused the function or misinterpreted the output?

    gap> a:=AbstractGenerator("a");;
    gap> b:=AbstractGenerator("b");
    gap> G:=Group(a,b);;
    gap> G.relators:=[];;
    gap> H:=CommutatorFactorGroup(G);;
    gap> AbelianInvariants(H);
    [ 0 ]                         

No, this is a genuine bug.  If the number of relators of the commutator
factor group is less than the number of generators, 'AbelianInvariants'
will drop infinite components.  Now the commutator factor group of a
group on $n$ generators has at least $n(n-1)/2$ relators (namely the
commutators), so the problem can only occur for the free group on 2
generators.

BTW, 'AbelianInvariants' for finitely presented groups has two more
problems.

It gives an error when applied to the free group on one generator.

It returns a list $l$ such that $h = Z/l[1]Z * Z/l[2]Z * Z/l[3]Z ... $,
but the elements are such that $l[1] | l[2] | l[3] ... $ (this is usually
called the Smith normal form, or elementary divisors).  On the other hand
the description of 'AbelianInvariants' states that the $l[i]$ shall all
be prime powers (this is usually called primary decomposition).  It is of
course easy to convert between those two representations.

All three problems shall be fixed in the next upgrade.  Then it will also
be allowed to apply 'AbelianInvariants' to arbitrary groups, not just
abelian ones (allowing one to bypass the computation of the commutator
factor group, which can be costly for finitely presented groups with many
generators).

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



From ruberman@binah.cc.brandeis.edu Thu Apr 22 14:22:15 1993
From:       ruberman@binah.cc.brandeis.edu "Daniel Ruberman"
date:       Thu, 22 Apr 93 14:22:15 +0200
Subject:    GroupHomomorphismByImages

Are there any plans to implement the command GroupHomomorphismByImages
for homomorphisms of Finitely Presented groups to, say, permutation groups?
There is no theoretical obstruction to doing so, as it is a matter of checking
whether the images of the relators in the permutation group are all trivial.
Failing that, if anyone has written GAP routines to accomplish this task, could
they please let me know.

Thanks,
Daniel Ruberman
(ruberman@binah.cc.brandeis.edu)



From sibley@math.psu.edu Sun Apr 25 18:51:15 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Sun, 25 Apr 93 18:51:15 +0200
Subject:    Subgroup(Parent(g),elts)

I just discovered an oddity in GAP and am trying to figure out why it is
the way it is:  Subgroup(g,elts) works only when g is a parent group.

As far as I can see, this means that when I write programs, where I
don't know whether g is going to be a parent group or not, I should
actually use Subgroup(Parent(g),elts) instead of the above.  But why
does Subgroup not automatically use the parent of g, if that's what it
needs, rather than making me explicitly say to use it?  Or am I going
to get into trouble using Subgroup(Parent(g),elts)?


David Sibley        | "Accurate reckoning.  The entrance into knowledge
Amateur radio NT3O  |  of all existing things and all obscure secrets."
sibley@math.psu.edu |      -- The Rhind Papyrus



From martin@math.rwth-aachen.de Mon Apr 26 12:53:57 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 26 Apr 93 12:53:57 +0200
Subject:    Re: GroupHomomorphismByImages

Daniel Ruberman writes in his e-mail message of 1993/04/22

    Are there any plans to implement the command GroupHomomorphismByImages
    for homomorphisms of Finitely Presented groups to, say, permutation groups?

Which version of GAP do you use.  In GAP 3.2 you can do the following

    gap> g := FreeGroup( 2, "g" );;
    gap> g.relators := [ g.1^2, g.2^5, (g.1*g.2^-1)^3 ];;
    gap> h := Group( (1,2)(3,4), (1,2,3,4,5) );;
    gap> f := GroupHomomorphismByImages( g, h, g.generators, h.generators );;
    gap> IsHomomorphism( f );
    true
    gap> PreImages( f, SylowSubgroup( h, 2 ) );
    Subgroup( Group( g.1, g.2 ), 
    [ g.1^-1*g.2^-3*g.1^-1*g.2^-2*g.1^-1*g.2^-3*g.1^-1*g.2^-2*g.1^-1*\
      g.2^-1*g.1^-1*g.2^-1, g.2^-2*g.1^-1*g.2^-1*g.1^-1 ] )
    gap> Index( g, last );
    15

Is this not what you want?

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



From martin@math.rwth-aachen.de Mon Apr 26 14:01:30 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 26 Apr 93 14:01:30 +0200
Subject:    Re: Subgroup(Parent(g),elts)

David Sibley writes in his e-mail message of 1993/04/25:

    I just discovered an oddity in GAP and am trying to figure out why it is
    the way it is:  Subgroup(g,elts) works only when g is a parent group.

    As far as I can see, this means that when I write programs, where I
    don't know whether g is going to be a parent group or not, I should
    actually use Subgroup(Parent(g),elts) instead of the above.  But why
    does Subgroup not automatically use the parent of g, if that's what it
    needs, rather than making me explicitly say to use it?  Or am I going
    to get into trouble using Subgroup(Parent(g),elts)?

Each group is either a parent or a subgroup of a parent.  The idea is
that the parent may hold information that is needed for the subgroups.
For example for finitely presented groups the parent holds the
presentation.  Thus subgroups must be subgroups of a parent, they cannot
be subgroups of other subgroups (because those subgroups would not hold
the information needed).

Put another way, a parent is a structure in which computations are
performed, and GAP allows only few operations between subgroups of
different parents (basically only the set theoretic functions
'Intersection' etc.).

That 'Subgroup' requires a parent as first argument is a reminder to this
fact.  It is true, 'Subgroup' could automatically take the parent of the
first argument, but we found the current behaviour usefull.  It helped us
catch a few bugs, where we though a certain group was a parent, when in
fact it was not.

'Subgroup( Parent(g), elts )' should not cause any problems.  In fact,
such a construct appears fairly often in the library.

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



From fceller@math.rwth-aachen.de Wed Apr 28 11:05:37 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Wed, 28 Apr 93 11:05:37 +0200
Subject:    new version of the Weyl-package

Dear Mrs. and Mr. Forum,

A new version of the Weyl-package is available on "samson.math.rwth-aachen.de"
(and hopefully soon on "dehn.mth.pdx.edu" and "wuarchive.wustl.edu"):

    -r--r--r--  1 ftp         39155 Apr 28 10:32 weyl.tar.Z
    -r--r--r--  1 ftp         40641 Apr 28 10:32 weyl.zoo

It features the following improvements:

-----------------------------------------------------------------------------
Dear GAP-Forum,
there are some small changes and one bug fix in the 'weyl' package. (However,
every program written before should be 'upward compatible'.) You can see the
changes in the following examples:

# there are now non-cristallograhic (finite) Coxeter groups:
gap> CartanMat("H",3);
[ [ 2, E(5)^2+E(5)^3, 0 ], [ E(5)^2+E(5)^3, 2, -1 ], [ 0, -1, 2 ] ]

gap> CartanMat("H",4);
[ [ 2, E(5)^2+E(5)^3, 0, 0 ], [ E(5)^2+E(5)^3, 2, -1, 0 ], [ 0, -1, 2, -1 ], 
  [ 0, 0, -1, 2 ] ]

gap> CartanMat("I2",5);
[ [ 2, E(5)^2+E(5)^3 ], [ E(5)^2+E(5)^3, 2 ] ]

# there is now an 'operations' component in the Weyl group record so that 
# certain generic functions for domains will work for Weyl groups as well:

gap> W:=Weyl(last);
Weyl( [ [ 2, E(5)^2+E(5)^3 ], [ E(5)^2+E(5)^3, 2 ] ] )

gap> RecFields(W);
[ "isDomain", "isWeylGroup", "cartan", "dim", "degree", "N", "roots", 
  "matgens", "permgens", "parameter", "operations" ]

gap> Size(W);
10

Some other changes improve the algorithms for computing Kazhdan-Lusztig
polynomials and for calculations in Hecke algebras (which were rather
slow before). E.g., on our HP computer, the command
 
   'LeftCells( Weyl ( CartanMat( "F", 4 ) ) );'

now takes roughly 5 hours cpu time. 

There was a bug in the programs for calculating in Hecke algebras, namely
in the program which computed the inverse of a standard basis element.

These changes were motivated by reports from other users. I should be very 
glad about any further such comments and suggestions for improvements.

                                        Aachen, 28.4.93, Meinolf Geck



From aeb@win.tue.nl Wed Apr 28 17:52:07 1993
From:       aeb@win.tue.nl "A. E. Brouwer"
Date:       Wed, 28 Apr 93 17:52:07 +0200
Subject:    Interrupts etc.

The past few days I have noticed several instances where
interrupting GAP left me with a crippled version of GAP.
One more instance happened a moment ago: I said
gap> PrintRec(N);
where N was some permutation group
[B.t.w., PrintRec does not occur in the on-line help,
only in the chapter About Gap]
and this produced much more output than I liked.
So, I gave ^C. Afterwards, N was partially mangled:

  gap> N;
  ~
      gap> 
  gap> PrintRec(N);     
  ~gap> 
  gap> Size(N);
  729
      gap> Print(N);
  ~gap> c in N;
  Error, Record: right operand must have '~.operations.in'

Let me take this opportunity to ask a question.
Do there exist facilities to regard an elementary abelian group
as a vector space (and vice versa)?
Do there exist facilities to go back and forth between a (permutation)
group p^n:G with elem. ab. subgroup p^n and a matrix group G
(with matrices of order n over GF(p))?

Andries Brouwer



From fceller@math.rwth-aachen.de Thu Apr 29 10:39:26 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Thu, 29 Apr 93 10:39:26 +0200
Subject:    Re: Interrupts etc.

A.E. Brouwer writes:

    The past few days I have noticed several instances where
    interrupting GAP left me with a crippled version of GAP.
    One more instance happened a moment ago: I said

Yes, there is problem with interrupting GAP while printing.  In order
to avoid recursion while printing,  GAP marks the objects which are
already printed.  If you interrupt GAP while it is printing, some
objects are still marked, which causes this behavior.  We will try to
fix this in the next upgrade.

best wishes
  Frank



From sam@math.rwth-aachen.de Thu Apr 29 11:59:15 1993
From:       sam@math.rwth-aachen.de "Thomas Breuer"
Date:       Thu, 29 Apr 93 11:59:15 +0200
Subject:    vector spaces & modules

Dear Mrs. and Mr. Forum,

Andries Brouwer asks two questions concerning vector spaces, namely
whether elementary abelian groups can be regarded as vector spaces
and vice versa, and whether it is possible to describe the action of
a group on an elementary abelian subgroup via a matrix representation.

Here 'regard' and 'describe' apparently both mean that one has homomorphisms
between the group and the vector space resp. between the group and the
representation and its module.  As stated recently in another message
to the GAP forum, up to now there is no developed data structure
representing vector spaces and modules in GAP, so the desired homomorphisms
would not be of much help.  But as soon as these domains and some functions
dealing with them are available in GAP (hopefully in the next version),
the questions of Andries Brouwer can be answered 'yes'.

Thomas Breuer
(sam@ernie.math.rwth-aachen.de)


P.S.:  What Andries Brouwer tells about the strange behaviour of '~'
       of course describes a bug, but I cannot say anything about when
       it will be fixed.



From neubuese@math.rwth-aachen.de Thu Apr 29 17:20:24 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 29 Apr 93 17:20:24 +0200
Subject:    bugs and trouble

Dear GAP-forum,

After some discussion, we want to introduce a new address   

gap-trouble@math.rwth-aachen.de

The  idea  is the  following.  We have  observed  the  discussions and
reports in  the GAP-forum as well as in the mail that  some of us have
got privately about GAP. These fall roughly into four categories:

1. Reports on what I like to call "real bugs", i.e. on instances where
GAP  produces  a wrong  answer  to a  problem, an answer that the user
might  even  take  for  granted  and  thus  might  be  led   to  wrong
conclusions.  The  wrong abelian invariants,  on which Daniel Ruberman
reported  recently,  were  such a case.  (in  which Martin fortunately
could   at  least   clarify  that  this   was  a   rather  exceptional
malfunction).

*We  urge  that  each such case should by all  means  and as  soon  as
*possible be reported in the GAP-forum in order to minimize the danger
*that somebody is led to wrong conclusions.

2.   Reports  on annoying behaviour of GAP  such as that of  GAP after
interrupting   while  printing  that  Andries  Brouwer  reported  this
morning.  Such things  are clearly annoying, they may  cost the user's
time,  but  at  least  (s)he  cannot  be  led  to  wrong  mathematical
conclusions.  The same applies to inefficiencies. We have no objection
at  all if these are  sent to the GAP-forum, however more such reports
seem to be sent directly to a private address in Aachen, most often to
Martin  Schoenert.   We  ask  that such reports  if  not sent  to  the
GAP-forum are rather sent to the above address "gap-trouble".  Letters
sent to  that address  will automatically be  distributed to  a  small
group of people who  will jointly try to deal with the problems.  This
group will be started with Martin Schoenert (of course), Frank Celler,
Thomas Breuer and myself, but whoever is willing  to help us with  the
task to settle such deficiencies is invited to  join the group (please
just  tell  us  to  be  put on  the  address list).   Letters  sent to
"GAP-trouble"  will  get  an  individual  reply to the  sender  and in
addition we intend to give a report from time to time to the GAP-forum
summarizing the troubles  reported and our plans to  deal  with  them,
which may range from "yes  will be fixed in the next patch"  over "yes
but has to wait for the next  version" to "yes, but ...". We hope that
by this scheme we  cannot only  distribute the workload  a  little bit
more evenly, but also  to  minimize times of no reply when some  of us
are absent from Aachen.

3. Installation problems. The flood of them occurring in the GAP-forum
after the release  of GAP 3.2  even  led to  the proposal of a second
forum. While  we did  not follow  this suggestion, we think that if in
the future such problems are  also sent to "gap-trouble" and we report
only on important and more often  asked questions in the GAP-forum, we
achieve some better organisation in this respect, too.

4. Questions "How can I do in GAP ...?	"  or  "Can I do..?"  These we
would like to see further in the GAP-forum and we hope that often,  as
in  the  past,  helpful answers  will  come  from members of the forum
outside of Aachen.

The address "gap-trouble" will be operational from Friday, April 30.
We hope that it will be a useful innovation and ask you to use it.

Joachim Neubueser



From scherrc@rosevc.rose-hulman.edu Thu Apr 29 18:32:44 1993
From:       scherrc@rosevc.rose-hulman.edu "Chad Scherrer"
Date:       Thu, 29 Apr 93 18:32:44 +0200
Subject:    Finding subgroups in GAP

Is there a way in GAP to find all the subgroups of a given group, and if so,
what about finding all normal subgroups of a given group? I realize these
aren't of too great concern in doing most research, but I'm originally a Cayley
user, and am in the habit of looping tests over the set of subgroups or the set
of normal subgroups of a group. I'm currently in the process of switching over
to using GAP, and have found equivalent commands for most of the things I could
do in Cayley, but have had trouble finding any mention in the GAP documentation
of how to find subgroups. Is there a way to do this in GAP?

				Sincerely,

				Chad Scherrer
				scherrc@rosevc.rose-hulman.edu



From martin@math.rwth-aachen.de Thu Apr 29 18:55:12 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 29 Apr 93 18:55:12 +0200
Subject:    Re: Finding subgroups in GAP

Chad Scherrer writes in his e-mail messages of 1993/04/29

    Is there a way in GAP to find all the subgroups of a given group,
    and if so, what about finding all normal subgroups of a given group?

The function 'ConjugacyClassesSubgroups' will return the conjugacy
classes of subgroups of a given group (whose largest perfect subgroup
must have size <= 10000).  With

    List( ConjugacyClassesSubgroups(G), Representative );

you get a list of representatives of the conjugacy classes, i.e.,
one subgroups from each conjugacy class.  With

    Concatenation( List( ConjugacyClassesSubgroups(G), Elements ) );

you get all the subgroups.

Note that 'ConjugacyClassesSubgroups' is somewhat slow for large solvable
groups.  I have rewritten this function so that it is now faster.  This
new implementation will be made available in the third upgrade (sorry I
don't know when we will release this upgrade).

The function 'NormalSubgroups' will return a list of normal subgroups of
a given group.

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



From l.h.soicher@qmw.ac.uk Thu Apr 29 19:32:00 1993
From:       l.h.soicher@qmw.ac.uk "Leonard Soicher"
Date:       Thu, 29 Apr 93 19:32:00 +0200
Subject:    GRAPE

There is a bug in GRAPE, such that if you interrupt the 
CompleteSubgraphs function and quit the break loop, you may find
the  names  field changed of the graph you input to this
function. This has already been fixed in the QMW version of 
GRAPE, and will be fixed in the next public release of GRAPE.



From hulpke@abacus.concordia.ca Fri Apr 30 09:48:39 1993
From:       hulpke@abacus.concordia.ca "Alexander Hulpke"
Date:       Fri, 30 Apr 93 09:48:39 +0200
Subject:    Re: Finding subgroups in GAP

In his message, Chad Scherrer asked:

> Is there a way in GAP to find all the subgroups of a given group, and if so,
> what about finding all normal subgroups of a given group?

GAP provides routines for both tasks. Subgroups are computed using the
'Lattice' command, which computes the whole lattice of subgroups (and
stores conjugated subgroups is a somehow shortened form). In case you
really want to have a list of all subgroups for looping over them, you
might use

   l:=Lattice(g); # supposing g is your group
   s:=Flat(List(l.classes,Elements));;

Then the variable 's' will contain a list of all subgroups. If you
replace 'Elements' by 'Representative', you will obtain a list of
representatives of each conjugacy class of subgroups. 

For computing all normal subgroups, GAP provides the command
'NormalSubgroups'.

                        Yours,
 
                           Alexander Hulpke



From fceller@math.rwth-aachen.de Fri Apr 30 12:20:40 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Fri, 30 Apr 93 12:20:40 +0200
Subject:    BUG: polynomials over the rationals

Dear Mrs. and Mr. Forum,

there is a bug in the 'Gcd' and 'mod' routines for polynomials over
the rationals in GAP 3.2 Patchlevel 2.  As far as I can see the
routines will not give wrong result, but you *might* get a weird error
message using 'mod' or an infinite loop in 'Gcd'.  This will be fixed
in the next patch kit.

best wishes
  Frank



From fceller@math.rwth-aachen.de Thu May  6 13:52:24 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Thu, 6 May 93 13:52:24 +0200
Subject:    BUG: problems on HP9000

Dear Mrs. and Mr. Forum,

there is a problem with GAP running on HP9000, which was discussed in
"gap-trouble".  I will give a brief summary of this discussion.

If you start GAP with output redirection on HP9000 you *might* get an
error message, saying "gap: panic 'SyGetmem' detected corrupted heap!".
This error message is caused by a malloc from inside the C-library, we
will include a work around for this in the next patch level.

best wishes
  Frank



From kaym@math.wayne.edu Sat May  8 18:15:55 1993
From:       kaym@math.wayne.edu "Kay Magaard"
Date:       Sat, 8 May 93 18:15:55 +0200
Subject:    PermChars

Using the 3.1 version of GAP I noticed the following:

On the one hand I get:

gap> A:=CharTable("Symmetric",6);;
gap> PermChars(A,6);     
[  ]
gap> PermChars(A);
Error, Variable: 'mino' must have a value at
for <var>  in [ maxu .. mino ] ... in
suche( 2 ) called from
Permut( tbl, arec ) called from
PermChars( A ) called from
main loop
brk> quit;

On the other hand I get:

gap> A:=CharTable("S6");;
gap> PermChars(A,6); 
[ [ 6, 2, 0, 3, 0, 1, 0, 4, 2, 0, 1 ], [ 6, 2, 3, 0, 0, 1, 4, 0, 2, 1, 0 ] ]
gap> 


Does a generic character table need to be reordered before 
asking for permutaion characters? 
If so how?



From jcbhrb@cerf.net Mon May 10 01:33:23 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Mon, 10 May 93 01:33:23 +0200
Subject:    Calling a subroutine with a "list" instead of a "sequence"

gap-forum@samson.math.rwth-aachen.de

I hate bothering the forum with something this trivial, but I can't find 
anything in the manual that describes how to do the following: convert
a "list" into a "sequence" -- (I am using the terminology of Mathematica
where Sequence@@{1,2,3} returns 1,2,3 ).

For example I would like to call "Group" not with r arguments each consisisting
of a permeutation; but with a single argument consisting of a set of r 
permutations. 

  gap> Group( (1,2),(3,4),(5,6) );
  Group( (1,2), (3,4), (5,6) )

Obviously this doesn't work :

  gap> Group( [(1,2),(3,4),(5,6)] );
  Error, operations: power of list and integer is not defined at
  id := arg[1] ^ 0 ... in
  Group( [ (1,2), (3,4), (5,6) ] ) called from
  main loop

Thanks.

Jacob Hirbawi
JcbHrb@CERF.net

PS. I tried mailing this to gap-trouble@samson.math.rwth-aachen.de and
    trouble@samson.math.rwth-aachen.de but it bounced back. I must be 
    mis-remembering the name of the second forum; could someone remind me
    of it please.



From fceller@math.rwth-aachen.de Mon May 10 09:23:17 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Mon, 10 May 93 09:23:17 +0200
Subject:    Re: Calling a subroutine with a "list" instead of a "sequence"

Jacob Hirbawi writes:
    
         gap> Group( [(1,2),(3,4),(5,6)] );
         Error, operations: power of list and integer is not defined at
         id := arg[1] ^ 0 ... in
         Group( [ (1,2), (3,4), (5,6) ] ) called from
         main loop

It is the second possibility listed in the manual that you want:

    'Group( <list>, <id> )'
    
    'Group' returns a new parent group   G  generated by group elements  g_1,
    ..., g_n  of <list>. <id> must be the identity of this group.

The <id> is needed because one might want to generate the trivial
group, in which case the 'Group' function needs a hint what kind of
group is to be constructed.  In order to keep the calling convention
uniform one cannot omit the <id> even if the <list> is not empty.

    gap> l := [ (1,2,3), (2,3,4) ];
    [ (1,2,3), (2,3,4) ]
    gap> Group( l, () );
    Group( (1,2,3), (2,3,4) )

He continues:
    
	I tried mailing this to gap-trouble@samson.math.rwth-aachen.de and
        trouble@samson.math.rwth-aachen.de but it bounced back. I must be 
        mis-remembering the name of the second forum; could someone remind me
        of it please.

The correct address is "gap-trouble@math.rwth-aachen.de" without the
"samson".  However, IMHO, this message belongs to "gap-forum" not to
"gap-trouble", which should be used for technical problems concerning
installation.

best wishes
  Frank



From pfeiffer@dmi.ens.fr Mon May 10 15:34:22 1993
From:       pfeiffer@dmi.ens.fr "Goetz Pfeiffer"
Date:       Mon, 10 May 93 15:34:22 +0200
Subject:    Re: PermChars

In his message of 8 May 93 Kay Magaard described some difficulties
with the computation of permutation characters for the symmetric group
$S_6$ and asks:

> Does a generic character table need to be reordered before 
> asking for permutaion characters? 

Sometimes, yes.  'PermChars' expects the 1-character to be the first
one in the list 'irreducibles'.  This is not the case for tables
constructed by the generic table of symmetric groups.  These tables
are constructed in such a way that the labelling of the characters
coincides with the labelling of the conjugacy classes.  And the
partition $[1^n]$ which labels the identity is the label for the sign
character, not for the trivial one.  (I will use the smaller table of
the group $S_4$ as an example.)

   gap> s4:= CharTable("Symmetric", 4);;
   gap> DisplayCharTable(s4);
   S4
   
      2  3  2  3  .  2
      3  1  .  .  1  .
   
        1a 2a 2b 3a 4a
     2P 1a 1a 1a 3a 2b
     3P 1a 2a 2b 1a 4a
   
   X.1   1 -1  1  1 -1
   X.2   3 -1 -1  .  1
   X.3   2  .  2 -1  .
   X.4   3  1 -1  . -1
   X.5   1  1  1  1  1
   
   gap> s4.classparam;
   [ [ 1, [ 1, 1, 1, 1 ] ], [ 1, [ 2, 1, 1 ] ], [ 1, [ 2, 2 ] ], 
     [ 1, [ 3, 1 ] ], [ 1, [ 4 ] ] ]
   gap> s4.irredinfo;
   [ rec(
         charparam := [ 1, [ 1, 1, 1, 1 ] ] ), rec(
         charparam := [ 1, [ 2, 1, 1 ] ] ), rec(
         charparam := [ 1, [ 2, 2 ] ] ), rec(
         charparam := [ 1, [ 3, 1 ] ] ), rec(
         charparam := [ 1, [ 4 ] ] ) ]

After exchanging the first and the last character in the table 's4' by
the function 'SortCharactersCharTable' the function 'PermChars' will
do its job.

   gap> SortCharactersCharTable(s4, (1,5));
   (1,5)
   gap> PermChars(s4, 4);
   [ [ 4, 0, 4, 1, 0 ], [ 4, 2, 0, 1, 0 ] ]

There will be a more precise error message, if the 1-character is not
in the expected position, in the next version.

Goetz Pfeiffer.



From pfeiffer@dmi.ens.fr Mon May 10 15:53:57 1993
From:       pfeiffer@dmi.ens.fr "Goetz Pfeiffer"
Date:       Mon, 10 May 93 15:53:57 +0200
Subject:    BUG in 'SortCharactersCharTable'.

Dear Gap-Forum.

I  noticed a little  bug   in the function  'SortCharactersCharTable'.
This function, if called in the form

   'SortCharactersCharTable( <tbl> )'

with a character table <tbl> as its only argument, is supposed to sort
the characters in  '<tbl>.irreducibles'  and then  to apply  the  same
permutation to the list '<tbl>.irredinfo'.

This doesn't work right if the 1-character is not the first one in the
list 'irreducibles' and the table  contains more than one character of
degree one!

   gap> c2:= CharTable("Symmetric", 2);;
   gap> DisplayCharTable(c2);
   S2
   
      2  1  1
   
        1a 2a
     2P 1a 1a
   
   X.1   1 -1
   X.2   1  1
   
   gap> c2.irredinfo;
   [ rec(
         charparam := [ 1, [ 1, 1 ] ] ), rec(
         charparam := [ 1, [ 2 ] ] ) ]
   gap> SortCharactersCharTable(c2);
   (1,2)
   gap> DisplayCharTable(c2);
   S2
   
      2  1  1
   
        1a 2a
     2P 1a 1a
   
   X.1   1  1
   X.2   1 -1
   
   gap> c2.irredinfo;
   [ rec(
         charparam := [ 1, [ 1, 1 ] ] ), rec(
         charparam := [ 1, [ 1, 1 ] ] ) ]

This will be fixed in the next upgrade.  

(The form 'SortCharactersCharTable( <tbl>,  <perm> )' with an explicit
permutation as second  argument,  as suggested  in the  answer  to Kay
Magaard's letter, works.)

Goetz Pfeiffer.



From hulpke@abacus.concordia.ca Mon May 10 18:23:00 1993
From:       hulpke@abacus.concordia.ca "Alexander Hulpke"
Date:       Mon, 10 May 93 18:23:00 +0200
Subject:    Coefficients bug

Dear Forum,

Obviously, there is an error in the Coefficients routine for finite
fields, as this example shows:

    gap> V:=VectorSpace([ Z(5)^0, Z(5^2)^2 ],GF(5));
    VectorSpace( [ Z(5)^0, Z(5^2)^2 ], GF(5) )
    gap> b:=Base(V);       
    [ Z(5)^0, Z(5^2)^2 ]
    gap> c:=Coefficients(V,Z(5)^3);
    [ Z(5)^2, 0*Z(5) ]
    gap> c[1]*b[1]+c[2]*b[2];
    Z(5)^2

However FiniteFieldOps.Coefficients (which I could not find in the manual)
seems to work as expected and can be used to replace the faulty routine.

Alexander Hulpke



From sam@math.rwth-aachen.de Tue May 11 17:48:45 1993
From:       sam@math.rwth-aachen.de "Thomas Breuer"
Date:       Tue, 11 May 93 17:48:45 +0200
Subject:    Re: PermChars

Dear Mrs. and Mr. Forum,

Kay Magaard writes

>    Using the 3.1 version of GAP I noticed the following:
>    
>    On the one hand I get:
>    
>    gap> A:=CharTable("Symmetric",6);;
>    gap> PermChars(A,6);     
>    [  ]
>    gap> PermChars(A);
>    Error, Variable: 'mino' must have a value at
>    for <var>  in [ maxu .. mino ] ... in
>    suche( 2 ) called from
>    Permut( tbl, arec ) called from
>    PermChars( A ) called from
>    main loop
>    brk> quit;
>    
>    On the other hand I get:
>    
>    gap> A:=CharTable("S6");;
>    gap> PermChars(A,6); 
>    [ [ 6, 2, 0, 3, 0, 1, 0, 4, 2, 0, 1 ],
>      [ 6, 2, 3, 0, 0, 1, 4, 0, 2, 1, 0 ] ]
>    gap> 
>    
>    
>    Does a generic character table need to be reordered before 
>    asking for permutaion characters? 
>    If so how?

As Kay suspected and Goetz Pfeiffer told in his message to the forum,
the reason for the error message and the incorrect answer in the case
of the generic table is that the trivial character is not the first
one in the list of irreducibles.  Of course this is a bug (in fact there
are two bugs, since 'PermChars' calls different algorithms for the
calculation of all permutation character candidates or of all of a
prescribed degree), since according to the manual (section 'Conventions'),
no program shall expect the trivial character to be the first one.
These bugs will be fixed in the next upgrade.  In the current version of
GAP, the user should move the trivial character to the first position when
using 'PermChars', as proposed by Goetz.

Kind regards

Thomas Breuer
(sam@ernie.math.rwth-aachen.de)



From munemasa@math.sci.kyushu-u.ac.jp Wed May 12 11:08:49 1993
From:       munemasa@math.sci.kyushu-u.ac.jp "Akihiro Munemasa"
Date:       Wed, 12 May 93 11:08:49 +0200
Subject:    CharTable of grp of order 27

Dear Gap-Forum.

I  noticed a strange behavior in the function  'CharTable'.

gap> g27:=AllThreeGroups(Size,27,IsAbelian,false);
[ Group( a1, a2, a3 ), Group( a1, a2, a3 ) ]
gap> G:=g27[1];; G.name:="G";;
gap> t1:=CharTable(G);;
Error, List Element: <list>[1] must have a value at
r := RootInt( Int( (D.deg - (D.num - anz) * D.degreePool[1][1] ^ 2) / anz ) )
  ... in
DegreeCandidates( D, d * mult ) called from
SplitTwoSpace( D, raum ) called from
CombinatoricSplit( D ) called from
DixonSplit( D ) called from
arg[1].operations.CharTable( arg[1] ) called from
..
brk>

GAP successfully computed the character table of all solvable
nonabelian groups of order at most 100, except those of order 27.

Akihiro Munemasa



From hulpke@abacus.concordia.ca Wed May 12 16:28:17 1993
From:       hulpke@abacus.concordia.ca "Alexander Hulpke"
Date:       Wed, 12 May 93 16:28:17 +0200
Subject:    Re: CharTable of grp of order 27

Dear GAP-Forum,

Akihiro Munemasa noticed a bug (politely denoted by him only as 'strange
behaviour') in the 'CharTable' routine.
It will arise, if there is no 'freedom' for the degrees of the non
linear characters, i.e. if the character degrees are determined exactly
by the number of classes and the number of linear characters.
In this case, due to a forgotten '=', the largest character
degrees are accidently thrown away, leading to problems.
Fixing this bug fortunately is very easy (though I hope, this fix will also
be included in the next patch): In the library file grpctbl.g change
line 272 (which also is identified uniquely by its contents) from

    D.degreePool:=Filtered(D.degreePool,i->i[1]>1 and i[1]<z/2);

to

    D.degreePool:=Filtered(D.degreePool,i->i[1]>1 and i[1]<=z/2);

> GAP successfully computed the character table of all solvable
> nonabelian groups of order at most 100, except those of order 27.

With this fix, GAP will compute the character tables of all these
groups (and also the non solvable ones).

Side remark: 27 is a prime power. For groups of prime power order,
CharTablePGroup normally works somehow faster than CharTable. As we were
planning to use CharTablePGroup in these cases instead of the standard
Dixon/Schneider algorithm, I never checked the two nonabelian groups of
size 27. I better had. Please excuse this stupid bug.

Yours

       Alexander Hulpke



From tpd@aberystwyth.ac.uk Thu May 13 12:36:57 1993
From:       tpd@aberystwyth.ac.uk "T. P. McDonough"
Date:       Thu, 13 May 93 12:36:57 +0200
Subject:    A CharTable Problem.

The following is a brief report on some difficulties encountered in the
use of the CharTable function to get character tables of Weyl groups
of type D. A problem seems to occur for even rank. An additional
curiosity is that a character table is produced for W(D3) indicating
a group of order 24 whose identity has a centralizer of order 48.

Tom McDonough

=========================================================================

Extracts from various GAP sessions, illustrating some problems
in attempting to generate the character tables for Weyl groups
of type D.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
gap> CharTable("WeylD",4);
Error, Range: <low> must be an integer at
for <var>  in [ i - k + 1 .. i - 1 ] ... in
CharValueSymmetric( n, BetaSet( alpha ), pi ) called from
CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 
 ) called from
gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] 
 ) called from
fun( i ) called from
List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from
..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
gap> CharTable("WeylD",6);
Error, Range: <low> must be an integer at
for <var>  in [ i - k + 1 .. i - 1 ] ... in
CharValueSymmetric( n, BetaSet( alpha ), pi ) called from
CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 
 ) called from
gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] 
 ) called from
fun( i ) called from
List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from
..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
gap> CharTable("WeylD",8);
Error, Range: <low> must be an integer at
for <var>  in [ i - k + 1 .. i - 1 ] ... in
CharValueSymmetric( n, BetaSet( alpha ), pi ) called from
CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 
 ) called from
gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] 
 ) called from
fun( i ) called from
List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from
..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
These commands were successful, but I haven't checked whether the
results are correct.
gap> CharTable("WeylD",5);
gap> CharTable("WeylD",7);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Finally, an interesting record.
gap> CharTable("WeylD",3);
rec( name := "W(D3)", order := 24, centralizers := [ 48, 8, 8, 4, 6 
 ], orders := [ 1, 2, 2, 4, 3 ], powermap := 
[ , [ 1, 1, 1, 2, 5 ], [ 1, 2, 3, 4, 1 ] ], irreducibles := 
[ [ 3, -1, -1, 1, 0 ], [ 1, 1, -1, -1, 1 ], [ 3, -1, 1, -1, 0 ], 
  [ 2, 2, 0, 0, -1 ], [ 1, 1, 1, 1, 1 ] ], classparam := 
[ [ 1, [ [ 1, 1, 1 ], [  ] ] ], [ 1, [ [ 1 ], [ 1, 1 ] ] ], 
  [ 1, [ [ 2, 1 ], [  ] ] ], [ 1, [ [  ], [ 2, 1 ] ] ], 
  [ 1, [ [ 3 ], [  ] ] ] ], irredinfo := [ rec(
      charparam := [ 1, [ [ 1 ], [ 1, 1 ] ] ] ), rec(
      charparam := [ 1, [ [  ], [ 1, 1, 1 ] ] ] ), rec(
      charparam := [ 1, [ [ 1 ], [ 2 ] ] ] ), rec(
      charparam := [ 1, [ [  ], [ 2, 1 ] ] ] ), rec(
      charparam := [ 1, [ [  ], [ 3 ] ] ] ) 
 ], text := "computed using generic character table for Weyl groups of type D"\
, classes := [ 1, 6, 6, 12, 8 ], operations := CharTableOps )
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 



From pfeiffer@dmi.ens.fr Thu May 13 12:00:53 1993
From:       pfeiffer@dmi.ens.fr "Goetz Pfeiffer"
Date:       Thu, 13 May 93 12:00:53 MET
Subject:    Re: A CharTable Problem.

In his message of 13 May 1993 Tom McDonough desrcibes

> some difficulties encountered in the
> use of the CharTable function to get character tables of Weyl groups
> of type D. 

These problems came into the package with the new concept for strings
in GAP.

The classes and characters of Weyl groups of type D are labelled by
pairs of partitions.  For even rank certain labels occur twice.  They
are distinguished by a "+" or "-" sign in the place of the second
partition.  The functions for the constuction of the character table
try to recognise these signed labels by 'IsString(pi[2])'.  

But the second partition may also be empty, represented by the empty
list.  And due to the new string concept, the empty list is now
recognised as a string, too.  This leads to the problems encountered
by Tom McDonough.

This will be fixed with the next upgrade.  Then the signs in the
labels will no longer be strings but single characters: '+' and '-'.
This means 'CharTable("WeylD", <n>)' and 'CharTable("Alternating",
<n>)' will then produce slightly different results.  I hope this
causes no problems.

In the meantime a possible workaround is to replace the function
'IsString' by one that ignores the empty list:


   gap> IsStr:= IsString;
   function (...) internal; end
   gap> IsString:= function(obj)
   > return obj <> [] and IsStr(obj); end;
   function ( obj ) ... end

WARNING: This might have side-effects in places where the empty string
is relevant.

But now it is possible to compute the tables and centralizers are
no longer bigger than the whole group.

   gap> CharTable("WeylD", 3);
   rec( name := "W(D3)", order := 24, centralizers := [ 24, 8, 4, 4, 3
    ], orders := [ 1, 2, 2, 4, 3 ], powermap :=
   [ , [ 1, 1, 1, 2, 5 ], [ 1, 2, 3, 4, 1 ] ], irreducibles :=
   [ [ 3, -1, -1, 1, 0 ], [ 1, 1, -1, -1, 1 ], [ 3, -1, 1, -1, 0 ],
     [ 2, 2, 0, 0, -1 ], [ 1, 1, 1, 1, 1 ] ], classparam :=
   [ [ 1, [ [ 1, 1, 1 ], [  ] ] ], [ 1, [ [ 1 ], [ 1, 1 ] ] ],
   ...

Goetz Pfeiffer.

PS: a detailed description of the implementation of the character
tables of Weyl groups and related groups will soon be available via
anonymous ftp from 'samson.math.rwth-aachen.de'.



From dfh@maths.warwick.ac.uk Wed May 19 16:44:44 1993
From:       dfh@maths.warwick.ac.uk "Derek Holt"
Date:       Wed, 19 May 93 16:44:44 +0200
Subject:    Query about finite fields

Dear GAP Forum,

I have a query about the construction of finite fields using the form

GaloisField(p,pol),

where pol is a polynomial.

The first remark is that this function does not in fact expect a GAP polynomial
at all, but a list of coefficients. That is not a serious problem, however.

My main problem is how to refer to the field elements once the field is
constructed. I want to refer to them as polynomials over the ground
field in the indeterminate  w, where  'pol'  is the minimal polynomial of  w
that I have specified. But how do I refer to  w?

If  w  is a primitive root, then it apparently is given by F.root.

e.g.

gap> F:=GF(2,[Z(2)^0, 0*Z(2), Z(2)^0,Z(2)^0 ]);
GF(2^3)
gap> F.root;
Z(2^3)^3
gap> MinPol(F.root);
[ Z(2)^0, 0*Z(2), Z(2)^0, Z(2)^0 ]
gap> 

but, in general,  w  may not be a primitive root and, if not, then  F.root
does not appear to get itself defined at all.

e.g.

gap> F:=GF(2,[ Z(2)^0, Z(2)^0, Z(2)^0, Z(2)^0, Z(2)^0 ]);
GF(2^4)
gap> F.root;
Error, Record: element 'root' must have an assigned value
gap> 

This is serious, because a lot of the GAP code that I have written for finite
fields uses the .root component. Is there any way that I can define F.root
in such a case without causing problems? Or do I have to make sure that I
only call the function for primitive elements?

Derek Holt.



From stiller@blaze.cs.jhu.edu Thu May 20 22:33:57 1993
From:       stiller@blaze.cs.jhu.edu "Lewis Stiller"
date:       Thu, 20 May 93 22:33:57 +0200
Subject:    Cayley graphs

Does anyone have software for looking  the Cayley graph or Cayley
color graph (also called the group graph) of a group in GAP; and the
related group action graph? (Given a group G generated by some
elements T and acting on a set X, the group action graph (G,T,X) has
as nodes X and an edge optionally colored t from each x\in X to each t
x\in x for each t\in T. ) Please reply via email.

Lewis Stiller
Department of Computer Science
The Johns Hopkins University
3400 North Charles St.
Baltimore, MD  21218-2194
stiller@cs.jhu.edu



From martin@math.rwth-aachen.de Thu May 20 22:44:24 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 20 May 93 22:44:24 +0200
Subject:    Re: Coefficients bug

Alexander Hulpke writes in his e-mail message of 1993/05/10:

    Obviously, there is an error in the Coefficients routine for finite
    fields, as this example shows:

This is correct.  In fact I would bet that there are more things in the
vector space package that are faulty.  Unfortunately I don't think that
this is very simple to fix.  We plan to rewrite the whole vector space
package (and add lots of related stuff, like modules).  We can not make
any promises when this will be available.

Alexander continues:

    However FiniteFieldOps.Coefficients (which I could not find in the manual)
    seems to work as expected and can be used to replace the faulty routine.

Again this is correct (at least I hope that 'FiniteFieldOps.Coefficients'
is correct, since I wrote it ;-).

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



From hulpke@abacus.concordia.ca Fri May 21 18:00:24 1993
From:       hulpke@abacus.concordia.ca "Alexander Hulpke"
Date:       Fri, 21 May 93 18:00:24 +0200
Subject:    Re: Query about finite fields

Dear GAP Forum,

In his letter, Derek Holt raised some questions concerning finite fields
and extensions. As I had to deal with similar problems recently, when
writing a routine to factor a polynomial over an algebraic extension, I
probably can give some advices on this them.

As I'm not the author of the finite fields routines, I cannot comment,
on modifying the 'root' component (however, I assume, that one might
create quite weird errors by setting this field to an element, which is
*not* a primitive root), myself I just would not dare to do such things.

> This is serious, because a lot of the GAP code that I have written for finite
> fields uses the .root component. Is there any way that I can define F.root
> in such a case without causing problems? Or do I have to make sure that I
> only call the function for primitive elements?

The question is: What will your code need the '.root' component for ?
Will it just need a primitive element of the extension, or does it rely
on the 'primitive root' property?
In the first case, I just would refer
to the component '.generators[2]' instead, which contains a root of the
generating polynomial, i.e. a primitive element. Otherwise of course,
you will have to select special polynomials (as the Conway polynomials).

> My main problem is how to refer to the field elements once the field is
> constructed. I want to refer to them as polynomials over the ground
> field in the indeterminate  w, where  'pol'  is the minimal polynomial of  w
> that I have specified. But how do I refer to w?

By F.operations.Coefficients (Do *not* use Coefficients, which contains
a bug) you can get the coefficients of a field element with respect to
the selected base. As GF selects a base to be powers ([0..d-1]) of a
primitive element, you will get exactly what you wanted, if you regard the
obtained coefficient list again as a polynomial.

Maybe this is of help. Yours

   Alexander Hulpke



From l.h.soicher@qmw.ac.uk Sat May 22 17:47:22 1993
From:       l.h.soicher@qmw.ac.uk "Leonard Soicher"
Date:       Sat, 22 May 93 17:47:22 +0200
Subject:    Re: Cayley graphs

Lewis Stiller asks about software to look at Cayley graphs and
group action graphs. 

What he needs is the GRAPE package for computing with graphs and
groups, which runs under the GAP system. In fact, GRAPE 2.1 is
about to be released as a GAP share package. 

For now, here is a sample GRAPE computation of a CAYLEY graph
for the symmetric group S4, and some calls to GRAPE functions
showing that this graph has diameter 4, girth 6, and an automorphism
group of order 144. 

gap> G:=SymmetricGroup(4);
Group( (1,4), (2,4), (3,4) )
gap> T:=G.generators;
[ (1,4), (2,4), (3,4) ]
gap> Cayley:=Graph(G,Elements(G),OnRight,function(x,y) return y/x in T; end);
rec(
  isGraph := true,
  order := 24,
  group := Group( ( 1, 2)( 3, 7)( 4, 9)( 5,11)( 6,13)( 8,16)(10,19)(12,21)
    (14,24)(15,23)(17,22)(18,20), ( 1, 3)( 2, 5)( 4,10)( 6,14)( 7,11)( 8,17)
    ( 9,18)(12,22)(13,23)(15,24)(16,21)(19,20), ( 1, 4)( 2, 6)( 3, 8)( 5,12)
    ( 7,15)( 9,13)(10,17)(11,20)(14,22)(16,23)(18,21)(19,24) ),
  schreierVector := [ -1, 1, 2, 3, 2, 3, 1, 3, 1, 2, 1, 3, 1, 2, 3, 1, 2, 2, 
      1, 3, 1, 2, 2, 1 ],
  adjacencies := [ [ 2, 3, 4 ] ],
  representatives := [ 1 ],
  names := [ (), (1,4), (2,4), (3,4), (1,2,4), (1,3,4), (1,4,2), (2,3,4), 
      (1,4,3), (2,4,3), (1,2), (1,2,3,4), (1,3), (1,3,2,4), (1,3,4,2), 
      (1,4,2,3), (2,3), (1,2,4,3), (1,4,3,2), (1,2)(3,4), (1,2,3), 
      (1,4)(2,3), (1,3)(2,4), (1,3,2) ] )
gap> Diameter(Cayley);
4
gap> Girth(Cayley);
6
gap> Size(AutGroupGraph(Cayley));
144
gap> quit;

L.H.Soicher@qmw.ac.uk



From neubuese@math.rwth-aachen.de Tue Jun  1 18:35:49 1993
From:       neubuese@math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 1 Jun 93 18:35:49 +0200
Subject:    Mr. Leonard's letter

In a letter of April 19 to the GAP-forum Frank Leonard wrote

>"I have been attempting some constructions of finite groups in GAP as
>defined  by  a  presentation  in  abstract  generators/relators.  The
>problem consists of applying a certain algorithm to construct a group
>which  I  then  attempt to identify. I also  have access to the  C.A.
>package  CAYLEY and have re-written the algorithm  for CAYLEY. I have
>found  CAYLEY vastly superior (time wise) to GAP for  this problem. I
>assume that the fact that GAP programs/functions are interpreted would
>be significant in explaining  the  discrepancies but  I am curious if
>there are any other factors which might be  significant. Can you tell
>me if there are any plans at present to write a compiler for GAP?"

In my  reply I  have made no attempt to  hide my disappointment  about
such  unspecified but nevertheless  very critical  comment.  On this I
have obtained a letter from Mr. Leonard which starts:

>"The  following  is  a  personal  message  and  is  not intended  for
>submission to the GAP-forum."

I  have to respect this.  However  I do  not think  that I  break this
confidentiality if I report that after saying later on in his letter:
>"I have been deliberately vague about the details of my constructions
>in my submission as the material on which I have based my GAP program
>forms the basis of a paper..."
Mr.  Leonard reports  that he  has used the  GAP-function Size(g) on a
two-generator, two-relator presentation  of the trivial group which he
then gives,  thus allowing us to analyze the case.  He states that  it
took him approximately 20 sec  using the GAP-command Size(g)  and less
than a  second in  Cayley to find that the presentation  does  in fact
describe the trivial group.

We have repeated the calculations and found  the statement correct, on
a DECstation Size(g) took 15 sec,  Cayley took 0.5 sec. I only wished,
Mr.  Leonhard had  made this  explicit statement in  his first letter,
because this gives me a chance  to  explain the reasons and talk about
consequences of the observation.

Both programs use Todd-Coxeter coset  enumeration methods. The  one in
Cayley is implemented  by George Havas in C, the one in GAP is written
by Martin Schoenert in the GAP-language with some  time-critical parts
in C  in the  GAP  kernel.  There is a  standalone  version of  Martin
Schoenert's program  written by him totally in C and so the first step
is a comparison of this and the GAP function.

The respective time for Martin Schoenert's  C program is 4.7  sec,  as
stated above  the time for the  GAP function  15  sec.  This factor is
rather typical, factors of 3 -  4 have  also been observed  with other
presentations.   This factor is due to two reasons, the fact  that GAP
is  interpreted  but also to the overhead time needed for  the dynamic
storage allocation  using  indirections. We do  not know exactly which
proportion of the factor  is due to which  of  the  reasons  but it is
clear that even compilation would not remove the second reason.  It is
also clear that both reasons hit  in particular with programs in which
rather  small  data  has to be accessed  many  times  and Todd-Coxeter
methods are one of the worst cases for this phenomenon.

There remains quite a substantial factor to be explained. The first to
note  is that there  are several  "strategies"  for  the  Todd-Coxeter
method, which can  have  an enormous,  unfortunately not  completely a
priori predictable influence on  the efficiency. There are some papers
investigating experimentally these various strategies, in particular

J.J. Cannon, L.A. Dimino,  G. Havas, J.M. Watson : Implementation  and
Analysis of the Todd-Coxeter  Algorithm.  Math.  of  Computation,  27,
(1973), 463 - 490.

G. Havas : Coset Enumeration Strategies. Proc. ISSAC 91.

and George Havas is carrying  out further investigations.

Without  going into  details:  There are  two  'old'  strategies,  the
so-called Felsch  strategy  and  the  so-called  HLT  strategy  (after
Haselgrove,  Leech,  and   Trotter),  of  which   'in  general'  (such
statements always have  exceptions,  and Mr. Leonard's example is one)
the Felsch method tends  to define  fewer redundant coset numbers  and
hence to need less space while the HLT  method  tends  to  be  faster.
(Both have been  improved by  modifications,  but this does not matter
too  much  here.)  Now the times observed  by Mr.  Leonard are for the
default strategies in GAP and Cayley.

The very short time  in Cayley is obtained by  a HLT strategy,  but as
George Havas, whom I want to  thank for his help  in investigating the
case, has pointed out,  also with a bit of luck: If he just cyclically
permutes the  relators,  his program  in CAYLEY takes  3 times  longer
because it defines  3 times more  coset  numbers before collapsing the
coset table!! (maximal table size 69909 instead  of  21860,  1.570 sec
instead of 0.530sec, times on his machine which I believe is a SUN)

The method used in GAP  is basically  a Felsch method, there is no GAP
implementatiom of a HLT based method yet.  Modifications of the method
cause rather drastic changes in efficiency of a Felsch method, too, as
in particular George Havas has investigated.  E.g.  using the relators
also as subgroup generators in a Felsch strategy mode of George Havas'
program reduces the maximal table  size from  27532 (which is the same
as in the GAP program) to 17012 and computing times  from 2.29 sec to
1.40 sec. This is because in George's program subgroup generators are
scanned a  la HLT.  Using in addition a 'Preferred Definition List', a
strategy developped  by  George Havas,  reduces the maximal table size
further to 9542 and the computing time 0.84 sec.

These figures make clear that the choice of the strategy is a delicate
matter and that the comparison made originally used defaults that were
particularly unlucky for the performance of GAP.

What are  the consequences  for us?   For very large enumerations  the
factor of 3 or 4 caused by indirection and interpretation is annoying.
We will therefore gratefully  accept  the  offer  of  George Havas  to
append  his  C-program,  which  at  present  probably  represents  the
greatest experience with the above mentioned delicate  decisions, as a
share library to GAP.   George will eventually provide us with  the  C
source code for the purpose, but he wants to polish the code first, so
we  may  first  try to  provide executables of  his  program for a few
computers.   Using  such  a  share  library of course has the drawback
(which is the payment for some of its speed) that it is running on its
own  piece of  storage that  is  not  administered by  the GAP storage
management.   Therefore we also  intend  to  learn more  from George's
experience and also try to improve the TC written in the GAP-language,
even if  more or less intrinsicly we will loose that factor of  3 or 4
against a standalone C-program.

This  has  become a long  letter,  allow  me  nevertheless  to mention
another case of an efficiency comparison. Both GAP 3.2 and CAYLEY have
programs  for the  computatipon  of the subgroup lattice, which we are
allowed to  compare  even more  since they  have  both been written in
Aachen.  The CAYLEY program was written by Volkmar Felsch,  originally
still in Fortran, then semiautomatically translated  into  C  by  John
Cannon.  Volkmar Felsch is still helping to maintain this program, the
last  such help  was given  only  this Spring.   The  GAP program  was
written by  Juergen Mnich.  Of course, when he had written it, we made
comparisons and were rather content with the results: For small groups
the  two performed roughly equal while for big permutation groups (big
for  this  kind  of program)  such  as the symmetric  group  S8 or the
Mathieu group  M12  the new program  was  faster by a factor  over 10,
which matters  for  these cases since absolute computing time is  over
one  hour  for the new program  for these  cases.  This  was at  least
partially due to the use of new functions for permutation  groups.  We
were rather surprised to learn from Ralf Dentzer  that the performance
of the  new  program was  not so satisfactory  for medium size soluble
groups with thousands of classes  of conjugate subgroups e.g.  certain
groups  of order 256  from  Eamonn  O'Brien's list for  which the  new
program performed by about the same factor of 10 *slower* than the old
one.  Martin Schoenert has very briefly mentioned this fact in a reply
to a question in the GAP-forum recently and also mentioned that he has
written  a still newer  progam  in  GAP which  seems  to  avoid  these
deficiencies for  medium size  soluble groups while keeping  the  good
performance for the 'big' groups. This program will be put into GAP in
the not too far future.

I mention the  second case after my report about the first in order to
make the  point that in cases such  as the computation of the subgroup
lattice of a 'big'  permutation group the fact that GAP is interpreted
and the storage management  uses indirections  does not  play  such an
important  role  for  the  efficiency  while  on the  other  hand  the
simplicity of programming in GAP makes  it much more feasable to try a
mathematical variant of a method that can improve the efficiency.

Last not least however I want to emphazise that we do appreciate clear
and  specific reports,  such as given  to  us  by  Ralf Dentzer, about
deficiencies in GAP, deficiencies which we shall then try to remove as
much and  as soon as our restricted manpower allows, and that the last
thing we want to do is to sweep such problems under the carpet.

Joachim Neubueser



From hulpke@abacus.concordia.ca Wed Jun  9 17:33:46 1993
From:       hulpke@abacus.concordia.ca "Alexander Hulpke"
Date:       Wed, 9 Jun 93 17:33:46 +0200
Subject:    GAP on DEC alpha machines

Dear Forum,

The subject line sais most: Has anyone compiled (and run) GAP
succesfully on a DEC alpha machine? I can compile it successfully, but
the garbage collector will crash.

Many thanks
                Alexander Hulpke



From caranti@volterra.cineca.it Mon Jun 14 11:38:48 1993
From:       caranti@volterra.cineca.it "A. Caranti"
Date:       Mon, 14 Jun 93 11:38:48 +0200
Subject:    GAP on DEC alpha machines

Dear Forum,

Alexander Hulpke writes

>   The subject line says most: Has anyone compiled (and run) GAP
>   successfully on a DEC alpha machine? I can compile it successfully, but
>   the garbage collector will crash.

This is just to report that  I've had the  same experience. I compiled
GAP with the  bsd option. But when it comes to running it, it does not
work:  long integer arithmetics gives  nonsense,  and any  attempt  of
doing anything results in a crash ("Memory fault").

I might add that a colleague of mine has had similar problems with a C
program of his: it compiles, but then crashes immediately.

Andreas Caranti



From dana@bimacs.cs.biu.ac.il Mon Jun 14 11:56:22 1993
From:       dana@bimacs.cs.biu.ac.il "Dana-Picard Noah"
Date:       Mon, 14 Jun 93 11:56:22 +0200
Subject:    installation

Dear Forum,
People here made for me the installation of GAP under UNIX. When I
tried to run it, as soon as I call to some function I get the
following message:

the library file 'filename' must exist and be readable in
ReadLib("filename") called from main loop

What have we to do?

Thanks a lot,
Thierry Dana-Picard.



From slinton@math.rwth-aachen.de Mon Jun 14 16:32:19 1993
From:       slinton@math.rwth-aachen.de "Steve Linton"
Date:       Mon, 14 Jun 93 16:32:19 +0200
Subject:    installation

   People here made for me the installation of GAP under UNIX. When I
   tried to run it, as soon as I call to some function I get the
   following message:

   the library file 'filename' must exist and be readable in
   ReadLib("filename") called from main loop

   What have we to do?

You need to tell GAP where to find it's library files. If you haven't
installed the library it can be obtained from whereever you got GAP in
the file lib3r2.zoo or lib3r2.tar.Z. If you have installed it already
then you should call GAP with the -l option to indicate where the
library is.

For example

gap -l /usr/local/gap/lib

An easy way to do this is to call gap by way of a shell script.
Typically the shell script is called /usr/local/bin/gap, and is
something like

#!/bin/sh
/usr/local/gap/src/gap -l /usr/local/gap/lib -h /usr/local/gap/doc $*


The -h option specifies the location of the documentation files used
to provide the on-line help.

You will have to change the path-names to suit your system.

	Steve Linton



From martin@math.rwth-aachen.de Mon Jun 14 16:48:01 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 14 Jun 93 16:48:01 +0200
Subject:    Re: GAP on DEC alpha machines

Alexander Hulpke writes in his e-mail message of 1993/06/09

    The subject line sais most: Has anyone compiled (and run) GAP
    succesfully on a DEC alpha machine? I can compile it successfully, but
    the garbage collector will crash.

GAP wont run on DEC Alpha machines.  The problem is that the storage
manager (Gasman) and the arbitrary integer package assume that the size
of a pointer and and an unsigned long integer are 32 bit.  On the Alpha
machines however, they are 64 bit large.  There is currently no fix for
that.

I have written a new storage manager that appears to work on the DEC
Alpha machines.  This storage manager will be in GAP 4.1.  We cannot make
any promises as to when this version will become available.

There is another approach that might be possible.  DEC offers a migration
tool that can be used to migrate binaries from DECstations (with the MIPS
R3000 processor) to binaries for the DEC Alpha machines (with the new
Alpha processor).  I dont know whether it would be possible to migrate
the GAP kernel this way, and in any case such a migrated kernel would run
slower than a kernel compiled on an Alpha.  But it would be worth a try
and would certainly be better than to wait for GAP 4.1.

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



From smith@pell.anu.edu.au Thu Jun 17 09:03:06 1993
From:       smith@pell.anu.edu.au "Michael Smith"
Date:       Thu, 17 Jun 93 09:03:06 +0200
Subject:    GAP on Mac

Hello  N.(?),

You said (quite some time ago) that as soon as GAP 3.2 was installed on
your mainframe, that it would be ported to the Mac.

Is this likely to happen soon?

Thanks,
Michael.

----------------------------/|-|--|-|--|------Michael-Smith-------------------
smith@pell.anu.edu.au      /_| |\ | |  |      Mathematics Research Section
--------------------------/--|-|-\|-|_/|------Australian-National-University--



From martin@math.rwth-aachen.de Thu Jun 17 09:40:32 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 17 Jun 93 09:40:32 +0200
Subject:    Stabilizer Chains

I would like to change the format of stabilizer chains for permutation
groups slightly.  Because they are described in the manual this would
violate our claim that we will remain compatible with what is described
in the manual.  The purpose of this message is to find out whether nobody
is relying on the format of stabilizer chains so that I can change it for
GAP 3.3, or whether I shall only make an intermediate change for GAP 3.3
and wait until GAP 3.4 with the full change.

I want to make two changes, of which only the first would be visible.

Currently the group itself is the top level stabilizer, e.g., the group
record itself has the components '<G>.orbit' and '<G>.stabilizer'.  I
want to change this so that the group record contains only the component
'<G>.stabchain', and it is this record that contains the components
'<G>.orbit' and '<G>.stabilizer' for the top level.  The idea behind this
is that all components in group record should be independent, so that a
user might delete those whithout the possibility to create inconsistent
group records (as would now happen if the user deleted only
'<G>.stabilizer').  This change is also needed for the second change.

The second change would be to change the base change function so that it
never changes stabilizer chains (destructively), but always creates new
stabilizer chains.  The idea behind this change is that quite a number of
functions must copy entire stabilizer chains, because that would fail if
the stabilizer chain was changed.  For example 'Stabilizer' (of a single
point or list of points), makes a base change, so that the new base
starts with the points to be fixed, and then installs a *copy* of the
remainder of the chain as chain of the stabilizer.  This copying could be
avoided if stabilizer chain would not be changed.

At the same time I will also change 'MakeStabChain' so that it will not
install the stabilizer chain into the group record, until it is complete.
The reason is that quite a few users have complained that after
interrupting a stabilizer chain computation, the group record was in an
inconsistent state (which will cause incorrect answers for 'Size',
'Centralizer', etc.).

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



From smith@pell.anu.edu.au Thu Jun 17 09:52:42 1993
From:       smith@pell.anu.edu.au "Michael Smith"
Date:       Thu, 17 Jun 93 09:52:42 +0200
Subject:    GAP on Mac

Dear GAP-forum readers,

My apologies. My last message was intended to be a message to N. S.
Mendelsohn, not to the forum. I'll try to be more careful in future.

Michael.



From mendel@ccu.umanitoba.ca Thu Jun 17 17:55:28 1993
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Thu, 17 Jun 93 17:55:28 +0200
Subject:    GAP on MAC

Harry Lakser tells me that GAP 3.2 for the Mac is almost ready.  The
original transfer was quite difficult, but now that he knows how to do it
the problem has become more or less routine.  The time delays are due to
the fact that Lakser has a number of other priorities.
N. S. Mendelsohn



From schwartz@symcom.math.uiuc.edu Fri Jun 18 00:55:57 1993
From:       schwartz@symcom.math.uiuc.edu "Gary K. Schwartz"
Date:       Fri, 18 Jun 93 00:55:57 +0200
Subject:    Table Libraries

I am having a problem creating libraries of character tables. I'm
running GAP 3.2 on a 486 PC. It seems that in the last paragraph of
section 46.6 of the manual, you say that the file which is printed by
PrintToLib must be edited, but there's no example and I don't
understand. Please give me an example starting with an arbitrary
character table that you want to save, and please include all the steps
from saving it, to notififying the library table, to reading it back.

Thank you
Gary Schwartz



From sam@math.rwth-aachen.de Fri Jun 18 17:41:27 1993
From:       sam@math.rwth-aachen.de "Thomas Breuer"
Date:       Fri, 18 Jun 93 17:41:27 +0200
Subject:    table libraries

Dear Mrs. and Mr. Forum,

Gary Schwartz writes in his message of today:

>  I am having a problem creating libraries of character tables. I'm
>  running GAP 3.2 on a 486 PC. It seems that in the last paragraph of
>  section 46.6 of the manual, you say that the file which is printed by
>  PrintToLib must be edited, but there's no example and I don't
>  understand. Please give me an example starting with an arbitrary
>  character table that you want to save, and please include all the steps
>  from saving it, to notififying the library table, to reading it back.


Here is an example.  Just now I realized that it might be not very
comfortable to include character tables in a private library.  In the
next version this will be a bit easier.

Let's say we are interested in the table of the symmetric group S3 ...

     gap> CharTable( "S3" );;
     #E CharTableLibrary: no library table with name 'S3'

.. but it is not in the library.  So let's add it.

     gap> g:= SolvableGroup( 6, 2 );
     S3
     gap> t:= CharTable( g );;
     gap> t.name;
     "S3"
     gap> PrintToLib( "table", t );

The file 'table' in the current directory contains the table.
We have to notify it, and want to allow access to it as 'mytable'.
(This must be done for every GAP session, for example statements like
this can be put into the '.gaprc' file.)

     NotifyCharTable( t.name, "table", [ "mytable" ] );

Now there are two problems.  The first is that GAP does not know
in which directories it shall search for the tables; therefore we
add the pathname of the directory to 'TBLNAME'.

     gap> TBLNAME;
     "/usd/gap/3.3/tbl/"
     gap> Append( TBLNAME, ";/usd/sam/tbl/" );

The second problem (or a bug in GAP, perhaps) is that table files
are expected to have an extension '.tbl', but our file has not yet.
(This will be fixed in the next version of GAP.)

     gap> Exec( "mv table table.tbl" );

Now we are done.

     gap> new:= CharTable( "mytable" );;
     gap> DisplayCharTable( new );
     S3
     
        2  1  .  1
        3  1  1  .
     
          1a 3a 2a
       2P 1a 3a 1a
       3P 1a 1a 2a
     
     X.1   1  1  1
     X.2   1  1 -1
     X.3   2 -1  .

Note that at the moment it might cause difficulties if the filename
contains special characters, e.g. '.'; this will also be fixed in the
next version of GAP.

Kind regards
Thomas Breuer
(sam@ernie.math.rwth-aachen.de)



From martin@math.rwth-aachen.de Mon Jun 21 09:58:42 1993
From:       martin@math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 21 Jun 93 09:58:42 +0200
Subject:    '<finite-field>.root'

We have received some e-mail messages asking about what the component
'.root' in a finite field record really is.

The component '.root' is only present if the finite field was contructed
as an extension with a primitive polynomial (i.e., one whose root is a
generator of the multiplicative group), and in this case it is one of the
roots of this polynomial.

If the finite field was constructed with an irreducible but not primitive
polynomial, the component '.root' is not present, but a root of this
polynomial is still available.  Namely the base of the new field as
vector space over the ground field consists of the first <degree> powers
of a root.  Thus '.generators[1]' is a root of the polynomial.

To clear up things a little bit we suggest the following name change
'.root' -> '.primitiveRoot' and plan to add a new component
'.primitiveElement'.  And of course we are also going to add the above
paragraphs to the manual.

Any objections?

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



From wright@bright.uoregon.edu Tue Jun 22 18:21:10 1993
From:       wright@bright.uoregon.edu "Charley Wright"
Date:       Tue, 22 Jun 93 18:21:10 +0200
Subject:    SubnormalSeriesPPermGroup

Greetings from Oregon, where it still hasn't stopped raining.

There is a minor problem with SubnormalSeriesPPermGroup. Here is an
example:

gap> C := Group((1,2,3,4));; C.name := "c4";;
gap> 
gap> sns := SubnormalSeriesPPermGroup( C );
[ c4, Subgroup( c4, [ (1,3)(2,4) ] ), Subgroup( c4, [  ] ) ]
gap> 
gap> sns[2].elements;
[ () ]
gap> 
gap> IsSubgroup(sns[2], sns[2]);
false

The wrong answer in IsSubgroup comes from the wrong value of sns[2].elements. 

The cause of the trouble seems to be a call to TrivialSubgroup in
SubnormalizerSeriesPPermGroup. TrivialSubgroup introduces the element (),
which then persists as the only element ever produced. It would be possible 
to revise SubnormalSeriesPPermGroup so as to maintain correct element lists 
of all the subgroups in the chains in generates, but it seems to make more 
sense simply not to generate any elements at all. The easy way to do that is 
to replace the line

	H := TrivialSubgroup(G);

by

	H := Subgroup(G, []);

in SubnormalSeriesPPermGroup. With this change, SubnormalSeriesPPermGroup
and CentralCompositionSeriesPPermGroup produce chains of subgroups for
which .element is not bound, and hence for which quotient factors can be
computed as called for.

The trivial subgroup strikes again!

Charley

wright@math.uoregon.edu



From aszczepa@umpa.ens-lyon.fr Wed Jun 23 11:52:29 1993
From:       aszczepa@umpa.ens-lyon.fr "A. Szczepanski"
date:       Wed, 23 Jun 93 11:52:29 METDST
Subject:    coxeter

Dear gap-forum,

Gerhard Hiss informed me that you can help me in the following problem:

How find the torsion free subgroup of finite index in the Coxeter

group ?

I have several examples of Coxeter groups for which I want to find

a torsion free subgroup of finite index.The simplest is:
   4    4            infinity
. -- . -- . -- . -- . -- . 

The Coxeter diagram ( linear) with 6 vertex and 5 edges.

The first two edges have "balanced" number 4 and the last edge has

number "infinity".

Thank you in advance.Sincerely Yours.Andrzej Szczepanski.



From wright@bright.uoregon.edu Wed Jun 23 20:44:33 1993
From:       wright@bright.uoregon.edu "Charley Wright"
Date:       Wed, 23 Jun 93 20:44:33 +0200
Subject:    CompositionSeriesSolvablePermGroup

A postscript to my last note:

CompositionSeriesSolvablePermGroup has the same difficulty that
SubnormalSeriesPPermGroup has. The TrivialSubgroup in its else branch
creates subnormal subgroups whose element lists only contain (), so that
IsSubgroup and its derivatives report that these subgroups have no subgroups
other than the trivial one.

Charley

wright@math.uoregon.edu

Charles R.B. Wright
Department of Mathematics
University of Oregon
Eugene, OR 97403



From kaym@math.wayne.edu Mon Jun 28 03:19:05 1993
From:       kaym@math.wayne.edu "Kay Magaard"
Date:       Mon, 28 Jun 93 03:19:05 +0200
Subject:    generic character tables

Dear Forum,

when trying to display a generic charater table I got the 
following:


gap> CharTable("Suzuki",8);;
gap> S:=last;;       
gap> DisplayCharTable(S);
Error, Record: element 'orders' must have an assigned value at
classes := [ 1 .. Length( tbl.orders ) ] ... in
DisplayCharTable( S ) called from
main loop
brk> quit;

Do generic charater tables come without tbl.orders? 

Kay Magaard



From sam@math.rwth-aachen.de Mon Jun 28 09:57:51 1993
From:       sam@math.rwth-aachen.de "Thomas Breuer"
Date:       Mon, 28 Jun 93 09:57:51 +0200
Subject:    Re: generic character tables

Dear Mrs. and Mr. Forum,

Kay Magaard writes in his message of today about a problem with
'DisplayCharTable', called with 'CharTable("Suzuki",8)'.  He asks

> Do generic charater tables come without tbl.orders? 

This depends on what components are bound in the generic table.
In this case, i.e., in 'CharTable("Suzuki")', no representative
orders and also no power maps are stored.

But of course this should not cause an error in 'DisplayCharTable',
and this bug will be fixed in the next version.

Kind regards

Thomas Breuer
(sam@ernie.math.rwth-aachen.de)



From gurican@alpha.dcs.mff.uniba.cs Tue Jun 29 12:04:41 1993
From:       gurican@alpha.dcs.mff.uniba.cs "Jaroslav Gurican"
Date:       Tue, 29 Jun 93 12:04:41 +0200
Subject:    Error in Manual for GAP 3.1 ?

Dear Gap-forum!
Reading the GAP 3.1 manual we were trying example at the bottom of the
page 91. The example reads as follows:

gap> A:=Z(3)*[[0,1],[1,0]];;B:=Z(3)*[[0,1],[-1,0]];;
gap> G:=Group(A,B);
Group( [ [ 0*Z(3), Z(3) ], [ Z(3), 0*Z(3) ] ],
[ [ 0*Z(3), Z(3) ], [ Z(3)^0, 0*Z(3) ] ] )
gap> Size(G);
8
gap> G.name:="G";
"G"
gap> d8:=Operation(G,Orbit(G,Z(3)*[1,0]));
Group( (1,2)(3,4), (1,2,3,4) )
gap> e:=OperationHomomorphism(Subgroup(G,[B]),d8);
OperationHomomorphism( Subgroup( G,
[ [ [ 0*Z(3), Z(3) ], [ Z(3)^0, 0*Z(3) ] ] ] ), Group( (1,2)(3,4),
(1,2,3,4) ) )

Uptill now  things go well. But we don't understand the following
error message:

gap> Kernel(e);
Error, Record: element 'permDomain' must have an assigned value at
if not d in G.permDomain ... in
stb.operations.Stabilizer( stb, pnt, OnPoints ) called from
GroupOps.Stabilizer( G, d, opr ) called from
arg[1].operations.Stabilizer( arg[1], arg[2], arg[3] ) called from
Stabilizer( hom.source, orb, OnTuples ) called from
fun( i ) called from
..
brk>

The correct answer (according to the manual) is:

Subgroup( G, [ ] )

Maybe we are missing some library file?
As the example is just rewritten from the manual, it should work.
 
Similar problems occur on the "top example" of the page 94 (the
example deals with the same group G as the previuos one).
The problem is in the computing of images.
GAP  computes Image (c, A), but not e.g Image(c, A*B) (the function
Image in this example seems to work only with generators A, B).

The problem seems to be due to the fact that the matrices are over
GF(3). The same things go well for the isomorfic group generated by
the same matrices, but over Q.  

	Jaroslav Gurican, Martin Skoviera



From fceller@math.rwth-aachen.de Tue Jun 29 17:38:49 1993
From:       fceller@math.rwth-aachen.de "Frank Celler"
Date:       Tue, 29 Jun 93 17:38:49 +0200
Subject:    Re: Error in Manual for GAP 3.1 ?

Dear Mr. and Ms. forum,

>>   Uptill now  things go well. But we don't understand the following
>>   error message:
>>
>>   gap> Kernel(e);
>>   Error, Record: element 'permDomain' must have an assigned value at
>>   if not d in G.permDomain ... in
>>   stb.operations.Stabilizer( stb, pnt, OnPoints ) called from
>>   GroupOps.Stabilizer( G, d, opr ) called from
>>   arg[1].operations.Stabilizer( arg[1], arg[2], arg[3] ) called from
>>   Stabilizer( hom.source, orb, OnTuples ) called from
>>   fun( i ) called from
>>   ..
>>   brk>
>>
>>   The problem is in the computing of images.
>>   GAP  computes Image (c, A), but not e.g Image(c, A*B) (the function
>>   Image in this example seems to work only with generators A, B).

This bug was fixed in GAP 3.1 Patchlevel 1:

    This  is  the  first upgrade for  GAP 3.1.  It brings version 3 release 1
    (V3R1) to version 3 release 1 patchlevel 1 (V3R1P1).

    The priority of this upgrade is low.

    [...]

    The function  'Image' was fixed to test  the  cases  correctly.   'Image'
    signalled an error when called to compute the image  of a  matrix under a
    mapping.

Please  update  to GAP 3.2, or if  you  do not have ftp access, try  at
least to upgrade to GAP 3.1 patchlevel 3.

best wishes
  Frank



From gurican@alpha.dcs.mff.uniba.cs Wed Jun 30 10:44:01 1993
From:       gurican@alpha.dcs.mff.uniba.cs "Jaroslav Gurican"
Date:       Wed, 30 Jun 93 10:44:01 +0200
Subject:    Re: Error in Manual for GAP 3.1 ?

Hello Frank,
thank you. I know that it is good idea to upgrade to 3.2. I have been
trying to get it since february, but there were problems with our ftp
connection. But in fact I have all things now, I am missing only grp3r2
library. I hope, I will be able to get it in a few days. (I have
problems with files bigger than 25 kBytes or so, but last saturday
I've got almost all *.zoo files - I've  simply forgot to get grp3r2).
	You promissed me your paper dealing with cohomology groups at
Budapest. I would like to have it (TeX file is enough, of course), if
possible. 
Best wishes, Jaroslav


