This file contains the mails sent to the GAP forum in October-December 1995.

Name                Email address                           Mails   Lines
Martin Schoenert    Martin.Schoenert@Math.RWTH-Aachen.DE        8     436
Steve Linton        sal@dcs.st-andrews.ac.uk                    8     142
Heiko Theissen      Heiko.Theissen@Math.RWTH-Aachen.DE          6     295
Claude Quitte       quitte@knuth.univ-poitiers.fr               4     386
Joachim Neubueser   Joachim.Neubueser@Math.RWTH-Aachen.DE       3     378
Andrew Mathas       a.mathas@ic.ac.uk                           3     144
Alexander Hulpke    Alexander.Hulpke@Math.RWTH-Aachen.DE        3     128
Thomas Breuer       Thomas.Breuer@Math.RWTH-Aachen.DE           3     123
Giovanni Ferrero    ferrero@prmat.math.unipr.it                 3      10
Frank Celler        Frank.Celler@Math.RWTH-Aachen.DE            2     214
Goetz Pfeiffer      goetz@dcs.st-andrews.ac.uk                  2     138
Chris Wensley       mas023@bangor.ac.uk                         2     104
Derek Holt          dfh@maths.warwick.ac.uk                     2     100
Jean Michel         jean.michel@ens.fr                          2      51
Werner Nickel       Werner.Nickel@Math.RWTH-Aachen.DE           2      38
Andries E. Brouwer  aeb@win.tue.nl                              2      29
Paul Robert Brown   pbrown@math.berkeley.edu                    2      26
Bruce Kaskel        kaskel@math.berkeley.edu                    2      17
Michael Smith       michael.smith@maths.anu.edu.au              1      87
Andreas Hoppe       hoppe@math.tu-berlin.de                     1      67
Andreas Prinz       prinz@informatik.hu-berlin.de               1      49
Dima Pasechnik      pasec@can.nl                                1      40
John Pliam          pliam@imafs.ima.umn.edu                     1      34
Burkhard Hoefling   hoefling@mat.mathematik.uni-mainz.de        1      32
Peter Prohle        prohlep@konig.elte.hu                       1      32
Peter F. Blanchard  pfb3h@weyl.math.virginia.edu                1      31
Wolfgang Knapp      wolfgang.knapp@uni-tuebingen.de             1      29
Sebastian Egner     egner@ira.uka.de                            1      26
Alessandro Logar    logar@univ.trieste.it                       1      25
Bettina Eick        Bettina.Eick@Math.RWTH-Aachen.DE            1      25
James McCarron      jmccarro@mercator.math.uwaterloo.ca         1      23
Shahiem Ganief      ganief@math.unp.ac.za                       1      23
David Wood          s8910859@student.ecel.uwa.edu.au            1      22
Olaf Delgado        delgado@mathematik.uni-bielefeld.de         1      21
David Sibley        sibley@math.psu.edu                         1      20
Kiechle Hubert      kiechle@mathematik.tu-muenchen.de           1      20
Stefan Neis         neis@cs.uni-sb.de                           1      20
Peter F. Mueller    pfm@math.ufl.edu                            1      19
Andreas Caranti     caranti@volterra.science.unitn.it           1      18
Marston Conder      conder@mat.auckland.ac.nz                   1      17
Lewis McCarthy      lmccarth@klingon.cs.umass.edu               1      16
Sarah Rees          sarah.rees@newcastle.ac.uk                  1       7
Robert Gilman       rgilman@sitult.stevens-tech.edu             1       4
Chris Charnes       charnes@osiris.cs.uow.edu.au                1       3
TOTAL                                                          85    3469

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 hoefling@mat.mathematik.uni-mainz.de Mon Oct  2 09:47:00 1995
Date:           Mon, 02 Oct 95 09:47:00 +0100
From:           "Burkhard Hoefling" <hoefling@mat.mathematik.uni-mainz.de>
Subject:        Re: new port of GAP for the Macintosh

Dear forum members
unfortunately there is a problem with the GAP 3.4.2 port for
the Macintosh which I uploaded last Friday. Somehow
part of the GAP 3.4.2 application's resources got lost. Moreover, I
forgot to include a source file, namely 'costab.mod.c'.  I've just
uploaded a corrected version into the pub/incoming directory at
ftp.math.rwth-aachen.de, which consists of the files

      bin3r4p2-mac-syc-pt101.sea.bin (the GAP application)
and   src3r4p2-mac-syc-pt101.sea.bin (the source files),

both in MacBinary II format. You only need the source files if you
want to compile GAP for Macintosh yourself. The old version (mac-syc-
pt10 files) must not be used any more and should be removed from the
server(s) as soon as possible. those who have already downloaded the
old version, I have created a patch file which updates  the GAP 3.4.2
PT 1.0 application. This file should be removed from the server(s)
in a week or so.

      bin3r4p2-mac-syc-pt10-patch.bin

which is available at the same location as the files above. You
only need this file if you already downloaded the file bin3r4p2-mac-
syc-pt10 this weekend. If you want to compile GAP for Macintosh
yourself, you should get the new source files, since they also
contain two or three minor fixes.Sorry for any inconveniences. I hope
that everything is all right now.

Sorry for any incomvenience.

Burkhard.



From thomas.breuer@math.rwth-aachen.de Mon Oct  2 12:04:00 1995
Date:           Mon, 02 Oct 95 12:04:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        TableAutomorphisms

Dear Mrs. and Mr. Forum,

Peter Blanchard wrote

> The following seems to be a problem in which
> the function TableAutomorphisms misses a symmetry:

He gives the following example.

    gap> DisplayCharTable( CharTablePGroup( TwoGroup( 16, 3 ) ) );



          2  4  4  4  4  3  3  3  3  3  3

            1a 2a 2b 2c 2d 2e 4a 4b 4c 4d
         2P 1a 1a 1a 1a 1a 1a 2a 2a 2c 2c

    X.1      1  1  1  1  1  1  1  1  1  1
    X.2      1  1  1  1 -1 -1  1  1 -1 -1
    X.3      1 -1  1 -1  1 -1  A -A  A -A
    X.4      1 -1  1 -1 -1  1  A -A -A  A
    X.5      1  1  1  1  1  1 -1 -1 -1 -1
    X.6      1  1  1  1 -1 -1 -1 -1  1  1
    X.7      1 -1  1 -1  1 -1 -A  A -A  A
    X.8      1 -1  1 -1 -1  1 -A  A  A -A
    X.9      2  2 -2 -2  .  .  .  .  .  .
    X.10     2 -2 -2  2  .  .  .  .  .  .

    A = E(4)
      = ER(-1) = i
    gap> TableAutomorphisms(tbl,tbl.irreducibles,"closed");
    Group( ( 7, 8)( 9,10), ( 5, 6)( 9,10), ( 2, 4)( 7, 9)( 8,10) )
    gap> (2,4) in last;
    false

Permuting the classes with (2,4) leaves the set of irreducible characters
invariant, namely it induces the permutation (X.9,X.10).
But we have computed the table automorphisms, that is, those automorphisms
of the matrix of irreducible characters that respect the power maps.
In our example this means that if we want to swap the classes '2a' and '2c'
then also their preimages under the 2nd power map must be swapped.
So the desired permutation must map { '4a', '4b' } to { '4c', '4d' }.
This leads to one of the permutations (2,4)(7,9)(8,10), (2,4)(7,10)(8,9)
of classes, which induce the permutations (X.2,X.6)(X.4,X.8)(X.9,X.10)
and (X.2,X.6)(X.3,X.7)(X.9,X.10) of characters.

Kind regards
Thomas Breuer



From pfm@math.ufl.edu Tue Oct  3 19:45:00 1995
Date:           Tue, 03 Oct 95 19:45:00 -0400
From:           "Peter F. Mueller" <pfm@math.ufl.edu>
Subject:        GeneralLinearGroup

Dear Gap-Forum,

if I understand the documentation correctly, then a command like

`GeneralLinearGroup(Permutations,2,2)'

should return the the group GL(2,2) as a permutation group (hopefully
in the natural representation, though that's not specified there).

However, the following happens (using GAP3R4P2):

gap> GeneralLinearGroup(Permutations,2,2);
Error, Record: element 'GeneralLinearGroup' must have an assigned value at
return arg[1].operations.GeneralLinearGroup( arg[1], arg[2], arg[3] ) ... in
GeneralLinearGroup( Permutations, 2, 2 ) called from
main loop

Peter M"uller



From thomas.breuer@math.rwth-aachen.de Wed Oct  4 17:17:00 1995
Date:           Wed, 04 Oct 95 17:17:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        Re: GeneralLinearGroup

Dear Mrs. and Mr. Forum,

Peter Mueller writes

    if I understand the documentation correctly, then a command like

    `GeneralLinearGroup(Permutations,2,2)'

    should return the the group GL(2,2) as a permutation group (hopefully
    in the natural representation, though that's not specified there).

He reports that in GAP3R4P2 this does not work.
The reason for this bug is that in spite of the promises in the manual
section 'The Basic Groups Library' nobody wrote the corresponding code.

The next upgrade will fix this, for general linear groups as well as for
special linear and symplectic groups, and general/special unitary groups.
For the moment, the following function should suffice.

    GeneralLinearPermGroup := function( n, q )

        local matgrp,   # the desired group as matrix group
              space,    # natural vector space 'matgrp' acts on
              vectors;  # set of nonzero vectors in 'space'

        matgrp:= GeneralLinearMatGroup( n, q );
        space:= GF(q)^n;
        vectors:= Elements( space );
        RemoveSet( vectors, Zero( space ) );

        return Operation( matgrp, vectors );
        end;

Kind regards
Thomas Breuer



From wolfgang.knapp@uni-tuebingen.de Fri Oct  6 09:52:00 1995
Date:           Fri, 06 Oct 95 09:52:00 +0100
From:           "Wolfgang Knapp" <wolfgang.knapp@uni-tuebingen.de>
Subject:        Wreath Product Action


Dear GAP forum,

for dealing with primitive permutation groups with the help of GAP it is
important to have an efficient way to implement in GAP the action of
degree m^k of the natural wreath product
 WreathProduct(Sym(m),Sym(k),IdendityMapping(Sym(k))),
usually called "product action" (I think "power action" is a more appropriate
name). Is it possible to avoid complicated and complex computations in
defining this action?

I would be grateful for any useful advice,         W. Knapp



------------------------------------------------------------------------------

Wolfgang D. Knapp

Mathematisches Institut                Internet:
Universit"at T"ubingen                 wolfgang.knapp@uni-tuebingen.de
Auf der Morgenstelle 10
                                       Tel. +49 7071 294318
D-72076 T"ubingen                      Fax  +49 7071 294322

GERMANY

-----------------------------------------------------------------------------



From dfh@maths.warwick.ac.uk Fri Oct  6 11:04:00 1995
Date:           Fri, 06 Oct 95 11:04:00 +0100
From:           "Derek Holt" <dfh@maths.warwick.ac.uk>
Subject:        Re:  Wreath Product Action


Wolfgang Knapp writes:

>
> Dear GAP forum,
>
> for dealing with primitive permutation groups with the help of GAP it is
> important to have an efficient way to implement in GAP the action of
> degree m^k of the natural wreath product
>  WreathProduct(Sym(m),Sym(k),IdendityMapping(Sym(k))),
> usually called "product action" (I think "power action" is a more appropriate
> name). Is it possible to avoid complicated and complex computations in
> defining this action?
>
> I would be grateful for any useful advice,         W. Knapp
>

I don't know whether there is a standard GAP function to do this, but
there does happen to be one in the share-package "smash".

It is called WreathPower(G,P) - G can be either a permutation or a
matrix group, and P must be a permutation group.

The source is in the file  main-gap-directory/pkg/smash/code/c_wreath.g
if you want to look at it.

Here is an example:

gap> RequirePackage("smash");
gap> G:=SymmetricGroup(3);
Group( (1,3), (2,3) )
gap> P:=SymmetricGroup(4);
Group( (1,4), (2,4), (3,4) )
gap> W:=WreathPower(G,P);
Group( ( 1, 3)( 4, 6)( 7, 9)(10,12)(13,15)(16,18)(19,21)(22,24)(25,27)(28,30)
(31,33)(34,36)(37,39)(40,42)(43,45)(46,48)(49,51)(52,54)(55,57)(58,60)(61,63)
(64,66)(67,69)(70,72)(73,75)(76,78)(79,81), ( 2, 3)( 5, 6)( 8, 9)(11,12)
(14,15)(17,18)(20,21)(23,24)(26,27)(29,30)(32,33)(35,36)(38,39)(41,42)(44,45)
(47,48)(50,51)(53,54)(56,57)(59,60)(62,63)(65,66)(68,69)(71,72)(74,75)(77,78)
(80,81), ( 2,28)( 3,55)( 5,31)( 6,58)( 8,34)( 9,61)(11,37)(12,64)(14,40)
(15,67)(17,43)(18,70)(20,46)(21,73)(23,49)(24,76)(26,52)(27,79)(30,56)(33,59)
(36,62)(39,65)(42,68)(45,71)(48,74)(51,77)(54,80), ( 4,28)( 5,29)( 6,30)
( 7,55)( 8,56)( 9,57)(13,37)(14,38)(15,39)(16,64)(17,65)(18,66)(22,46)(23,47)
(24,48)(25,73)(26,74)(27,75)(34,58)(35,59)(36,60)(43,67)(44,68)(45,69)(52,76)
(53,77)(54,78), (10,28)(11,29)(12,30)(13,31)(14,32)(15,33)(16,34)(17,35)
(18,36)(19,55)(20,56)(21,57)(22,58)(23,59)(24,60)(25,61)(26,62)(27,63)(46,64)
(47,65)(48,66)(49,67)(50,68)(51,69)(52,70)(53,71)(54,72) )
gap> Size(W);
31104


Derek Holt.



From heiko.theissen@math.rwth-aachen.de Thu Oct 12 16:46:00 1995
Date:           Thu, 12 Oct 95 16:46:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Announcement: List of primitive simple permutation groups

Dear forum readers,

I have put a file `coco.grp' into the `/pub/incoming' directory on our
ftp server   `ftp.math.rwth-aachen.de'.  This  file  contains   a  GAP
function that will construct the primitive permutation representations
of  simple groups  of   order less than  a   million,  except for  the
two-dimensional linear groups.

The information about  these  groups stems from  the  computer package
COCO (for computations with COherent COnfigurations)  written by A. A.
Ivanov, I. Faradzev and M. Klin (UNIX port by A. Brouwer) and has been
translated into GAP-format.

Details about the  new GAP function, including  instructions on how to
install  and  use it,  are  contained in the  short documentation file
`coco.tex' in the same   directory `/pub/incoming'. You can  run  this
file through plain TeX to produce a printed description (2 pages).

Have fun, Heiko Thei{\ss}en



From logar@univ.trieste.it Mon Oct 16 12:56:00 1995
Date:           Mon, 16 Oct 95 12:56:00 +0100
From:           "Alessandro Logar" <logar@univ.trieste.it>
Subject:        a question

Dear Gap Forum,
here is probably a trivial question on GAP, but at least after a
first glance at the manual, I was not able to find an answer.
(I have to add that I am definitely not a gap expert...)
My problem is (or can redeuced to) the following:
I want to define a function, say F(n), such that, for a given n, F(n)
returns the free group generated by x1,...,xn.
The funcion FreeGroup, as far as I can understand, do not allows to
have as an argument, a sequence of element as x1, ..., xn for a
generic n.
I would greately appreciate any suggestion.
Let me ask another question: is there a guide to GAP which is
reasonabely quick to read? The manual is surely extremely complete,
but I have to confess that in front of the 1,200  pages I am a
little scared ...

Thank you for the attention.

    Greetings.


    Alessandro Logar (Math. Dept., University of Trieste, Italy)

    e-mail: logar@univ.trieste.it



From sibley@math.psu.edu Mon Oct 16 15:34:00 1995
Date:           Mon, 16 Oct 95 15:34:00 -0400
From:           "David Sibley" <sibley@math.psu.edu>
Subject:        Re: a question

You wrote:
>Let me ask another question: is there a guide to GAP which is
>reasonabely quick to read? The manual is surely extremely complete,
>but I have to confess that in front of the 1,200  pages I am a
>little scared ...

Reading the first chapter should be plenty to get you going.  Use the
rest as a reference manual.  That's what I did.  I don't think the
organization of the manual has changed that much since then, although
it has grown.

I'm not sure about the answer to your other question.  I'd have to
check to see whether what I have in mind would work.


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
<URL:http://www.math.psu.edu/sibley/>



From alexander.hulpke@math.rwth-aachen.de Tue Oct 17 10:08:00 1995
Date:           Tue, 17 Oct 95 10:08:00 +0100
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: a question

Dear GAP Forum,

Alessandro Logar asked:

> (I have to add that I am definitely not a gap expert...)
> My problem is (or can redeuced to) the following:
> I want to define a function, say F(n), such that, for a given n, F(n)
> returns the free group generated by x1,...,xn.
> The funcion FreeGroup, as far as I can understand, do not allows to
> have as an argument, a sequence of element as x1, ..., xn for a
> generic n.
> I would greately appreciate any suggestion.

I'm not completely sure whether this is your question, but I'll try to
explain a bit better how one can use 'FreeGroup'.
You have 4 possibilities to create free groups. They all give different
names (for printing) to the generators, from a mathematical or algorithmic
point of view they are all equivalent:

  gap> f:=FreeGroup(3);
  Group( f.1, f.2, f.3 )

  gap> f:=FreeGroup(3,"x");
  Group( x.1, x.2, x.3 )

  gap> f:=FreeGroup(["a","b","c"]);
  Group( a, b, c )

You can access the generators via their record components f.1,f.2 and f.3
(or f.generators[nr]). So with the last example one would get

  gap> f.2^2;
  b^2

(It is important to distinguish between variables and their names,
i.e. the way they are printed).

The fourth version will not be supported any longer in GAP 4.x as it might
lead to confusion. It's just mentioned for sake of completeness:

  gap> x1:=AbstractGenerator("a");
  a
  gap> x2:=AbstractGenerator("b");
  b

  The names are completely independent of the generators. As you see we can
  even give the same name to different generators:

  gap> x3:=AbstractGenerator("a");
  a
  gap> Group(x1,x2,x3);
  Group( a, b, a )
  gap> AbelianInvariants(CommutatorFactorGroup(last));
  [ 0, 0, 0 ]

  So x1,x2 and x3 are all distinct, though x1 and x3 are called the same.

Alexander Hulpke



From pfb3h@weyl.math.virginia.edu Wed Oct  4 10:38:00 1995
Date:           Wed, 04 Oct 95 10:38:00 -0600 (MDT)
From:           "Peter Floodstrand Blanchard" <pfb3h@weyl.math.virginia.edu>
Subject:        Re: TableAutomorphisms

Dear Thomas,
        Thank you for your explanation of my perceived problem with the
TableAutomorphism function.  I should have slept on it before seeking
help, as I did eventually figure out my difficulty.  My mind quite
stubbornly insisted in viewing the situation incorrectly.  Anyway I
did see the problem by making use of one of my favorite features
of GAP, namely access to the libraries.  It was a simple matter to

i). Make a temporary copy of the library file containing the
TableAutomorphisms function.

ii). Locate the code which checks that a proposed permutation
respects the powermaps.

iii). Insert a statement to print out the proposed permutations
just before and after checking them.

Being able to examine the calculations in this way allowed me to
see my error immediatly.

One can also use access to the library files to customize some
functions. For example, one may want to insert statements printing
out data which will help determine whether a calculation is going to
take 2 minutes or 2 years!

Anyway thanks again for you response.
Thanks also to all the GAP folks for their wonderful work.


Peter Blanchard



From lmccarth@klingon.cs.umass.edu Thu Oct 12 03:52:00 1995
Date:           Thu, 12 Oct 95 03:52:00 -0400
From:           "Lewis McCarthy" <lmccarth@klingon.cs.umass.edu>
Subject:        Origins of GAP

Dear GAP Forum-

For a paper I'm writing I want to include a brief discussion of the origins
and history of GAP. Joachim Neubuser's June `94 preface to the GAP manual
has proven invaluable in this regard. However, I remain partly unclear about
the original motivations for creating GAP. Specifically, what aspects of
(for example) the CAYLEY system (now MAGMA) and the work of Pless/Leon et al.
at UIC made those systems undesirable in contrast to the GAP design ?

Thanks in advance for any comments on this topic. (Perhaps I should mention
that there are no current plans to publish this paper in a research journal.)

<a href="mailto:lmccarth@cs.umass.edu">-Lewis McCarthy</a>

P.S. Is the preface on the GAP manual web page somewhere ?



From pliam@imafs.ima.umn.edu Thu Oct 12 18:20:00 1995
Date:           Thu, 12 Oct 95 18:20:00 -0500 (CDT)
From:           "John Pliam" <pliam@imafs.ima.umn.edu>
Subject:        Re: Rubik's Cube

>
>
>     In January of 1994, I wrote a small package for describing elements of a
> permutation group in terms of its generators.  There were some inefficiencies,
> and the results were far from optimal, but it gives reasonable results, and
> reasonably quickly.  For example, for Rubik's Cube, it takes less than a minute
> to "familiarize itself" with the cube.  After this, I chose a random element
> of the group, and ask for the solution.  The calculations took .017 seconds.
> The solution involved about 1200 moves.  The worst case has about 1575 moves.
> Much better than the 500,000 mentioned, but far short of optimal.  I used
> another routine to find a shorter version of the solution.  This gives a
> further reduced word, but it is still not optimal.  In my last run, 85 seconds
> of "Shrinking" gave a word of length 135.  Of course, the timing results are
> machine dependent.  I am using a Sun workstation.
>
>    I placed the package in /pub/incoming at
> ftp@samson.math.rwth-aachen.de with the non-obvious name of AbStab.  (This
> is for "Abstract Stabilizer Chains.")
>
>    I haven't heard comments about it, and was curious as to if anyone has
> used it, or if it has been moved to another location.

Phil,

Hi, How's it going?  I saw this on the Gap forum and was wondering what
is the worst case minimum # of moves (diameter of the Cayley graph)?
Does anyone know?   I have read claims of like 50?

I have become interested in this again, because of applications to routing
in parallel archectures (I actually found papers using the Schreier thm.
in eng. journals :-)

John Pliam



From sal@dcs.st-andrews.ac.uk Tue Oct 17 18:13:00 1995
Date:           Tue, 17 Oct 95 18:13:00 +0100
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        Re: Rubik's Cube


[ On representing group elements in terms of generators ]

> I have become interested in this again, because of applications to routing
> in parallel archectures (I actually found papers using the Schreier thm.
> in eng. journals :-)
>

Gene Cooperman <gene@ccs.neu.edu> and Larry Finkelstein <laf@ccs.neu.edu> have
done some recent work on this sort of computation. In particular, I think they
solved the 2x2x2 Rubik's cube.

        Steve



From joachim.neubueser@math.rwth-aachen.de Wed Oct 18 12:18:00 1995
Date:           Wed, 18 Oct 95 12:18:00 +0100
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Re: Origins of GAP

Dear GAP Forum,

Lewis McCarthy asked:

> For a paper I'm writing I want to include a brief discussion of the origins
> and history of GAP. Joachim Neubuser's June `94 preface to the GAP manual
> has proven invaluable in this regard. However, I remain partly unclear about
> the original motivations for creating GAP. Specifically, what aspects of
> (for example) the CAYLEY system (now MAGMA) and the work of Pless/Leon et al.
> at UIC made those systems undesirable in contrast to the GAP design ?

Since we have established the tradition  to answer all questions posed
in the GAP forum, we have to  answer this one, too, and  I am afraid I
have to answer. I discussed possible answers with  some members of our
team and a  very short  formulation proposed was:   'We  did not  like
Cayley, we did like Maple, and fortunately we did  not realize what we
were going in for.' All three parts of that statement are true and the
last  one  even more than  the  first two, if e.g.   I think of myself
writing this letter just now.

But seriously now:

Very clearly Cayley  was a very strong  and in  many ways userfriendly
system  already when we started GAP  and had been  used by many people
with great success. It was not, and Magma  still is not, however, what
I call an  'open' system in the  preface  to the GAP  manual.  Various
aspects of what I mean by that are detailed  in the last section 'Some
concerns' of my paper  'An  Invitation to Computational  Group Theory'
which  is  printed  in   Campbell    et  al.,  ed's.,   Groups    '93,
Galway/St.Andrews,  vol.  2, p.   457 - 475,  (and which is also on my
web  page).  This paper rather  closely follows a  talk that I gave on
the first day  of that conference as an  introduction to a workshop on
CGT that we organised during the second week, and which I (ab?)used to
express some rather personal opinions.

I  should mention perhaps that   at an earlier  time  of the so-called
'Aachen Sydney Group System' which was a  forerunner of Cayley as well
as of the first version of the system of Vera Pless, we had cooperated
very closely with John Cannon, and though of course the code from that
time has meanwhile been tranlated from Fortran to  C and over and over
improved  and rewritten  by  him, at least  at the  time  of the first
release of Magma  there   were still some  parts   of  code (in   this
transformed state) in   Magma, which originated  from Aachen.  However
even at the time of close cooperation when we had a copy of the source
of the  group theoretical  functions of the  system  we still had  not
access to all, e.g.  we were not able to experiment with modifications
of the language.

> Thanks in advance for any comments on this topic. (Perhaps I should mention
> that there are no current plans to publish this paper in a research journal.)

Glad to hear  that, I hope that neither   GAP nor even me have  become
history yet.

> P.S. Is the preface on the GAP manual web page somewhere ?

No.

Kind regards      Joachim Neubueser



From prinz@informatik.hu-berlin.de Wed Oct 18 15:21:00 1995
Date:           Wed, 18 Oct 95 15:21:00 +0100 (MET)
From:           "Andreas Prinz" <prinz@informatik.hu-berlin.de>
Subject:        IsConjugate

Hi there,

I found a somewhat strange behaviour of IsConjugate
is the following case:

game:= Group(
( 1, 3, 8, 6)( 2, 5, 7, 4)( 9,33,25,17)(10,34,26,18)(11,35,27,19),
( 9,11,16,14)(10,13,15,12)( 1,17,41,40)( 4,20,44,37)( 6,22,46,35),
(17,19,24,22)(18,21,23,20)( 6,25,43,16)( 7,28,42,13)( 8,30,41,11),
(25,27,32,30)(26,29,31,28)( 3,38,43,19)( 5,36,45,21)( 8,33,48,24),
(33,35,40,38)(34,37,39,36)( 3, 9,46,32)( 2,12,47,29)( 1,14,48,27),
(41,43,48,46)(42,45,47,44)(14,22,30,38)(15,23,31,39)(16,24,32,40)
);

p1:=(3,19,43,33,8,24,27,25,30)(5,21,45,47,44,42,36)
    (14,22,32,40,16,48,46,41,38)(15,23,29,26,28,31,39);
p2:=(6,16,19,17,22,8,11,41,25)(7,13,42,45,47,44,28)
    (14,24,32,40,43,48,46,30,38)(15,21,18,20,23,31,39);

IsConjugate(game,p2,p1);
IsConjugate(game,p1,p2);


Both of the calls yield >>true<<, but the first one is
very very very much faster (in fact, I only once waited
for the second to terminate - it was almost 30 mins on
a sun sparc as compared to less than 10 secs for the first
case).

Is this a bug or a feature?

For my work it would suffice to order the two elements such
that the faster version is used. Is there a way to do so?
(If there is, it should be included into IsConjugate!)

Another thing is the output using the Print routine.
On my system I get for long lines extra characters \\ and \n.
Is there a way to avoid this?

I just tried to program something like a counter in place,
i.e. without scrolling put always the new numbers onto the
old terminal position. Is there a solution to this already
available?
(Currently, I solved the problem by doing some dirty tricks
with terminal special characters (e.g. <esc>[4h ...)

Regards,
   Andreas



From kaskel@math.berkeley.edu Wed Oct 18 10:14:00 1995
Date:           Wed, 18 Oct 95 10:14:00 -0700
From:           "Bruce Kaskel" <kaskel@math.berkeley.edu>
Subject:        Re: Origins of GAP

Oh, BTW, is there some reason why you uuencode a message such as the last one?
uuencoding is meant for things like sending binary files through the mail
like when you often send me a .zip file. If you just have a short text message
it doesn't make much sense to uuencode. Perhaps you are just "attaching" the
text file to the mailing message and i-2000 is uuencoding it? But attaching
is what you used to do at hofbbs, do you do something similarat i-2000?

--Bruce



From kaskel@math.berkeley.edu Wed Oct 18 12:17:00 1995
Date:           Wed, 18 Oct 95 12:17:00 -0700
From:           "Bruce Kaskel" <kaskel@math.berkeley.edu>
Subject:        apology


Dear GAP-forum members,

        I mistakenly sent a private message (of little conseqence)
to the GAP-forum earlier today. I am sorry for the mistake.

--Bruce Kaskel



From heiko.theissen@math.rwth-aachen.de Thu Oct 19 15:39:00 1995
Date:           Thu, 19 Oct 95 15:39:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: IsConjugate / Print (fwd)

Dear forum readers,

1.  Andreas  Prinz has reported  a strange  behaviour of  the function
`IsConjugate'. This is no bug, it really is a feature.

The conjugacy test whether <a> is conjugate to <b> in <G> is performed
by a backtrack  search over <G>  where elements are considered in turn
and for each such element <g> it is tested whether $a^g = b$. A search
tree is used  to determine the order of  the search and this tree also
makes it possible to

  - discard large subtrees of elements because they can never
    conjugate <a> to <b> and
  - consider only one element per coset of the centralizer of <b>.

The  special  structure of  the  search tree  is   based on the  cycle
structure of <a> and on the base chosen for <G>. `IsConjugate' returns
`true' when one conjugating element is found.

Now in the fast variant of Andreas Prinz's example the *first* element
considered in  this way was  already a conjugating element, whereas in
the  slow variant  (with <a> and   <b> interchanged) only the 103681st
element did it. That's why it took so much longer.

Since  the order in which the  elements are considered  depends on the
ordering of the basic  orbits inside the stabilizer  chain of <G>, the
only way I see which could catch  this (rather exceptional) case would
be to set  up the search tree for  either choice of  <a>  and then see
whether  the  first element  (or one  of the first   ten, or the first
hundred?) conjugates  <a>  to <b>. Better  suggestions  are of  course
welcome.

2. Andreas Prinz  also asked why  he gets  extra  characters when long
lines  are printed. I assume he  meant that GAP  prints a slosh `\' in
the 79th column (leaving the  80th column blank)  and continues in the
next line when it prints  a string that is  longer than 78 characters.
(This applies  to an 80 column screen.)  GAP certainly never prints an
extra `\n' (or was a newline character meant?).

If you use `SizeScreen(  [ <nrcols>, <nrrows>  ] )', GAP behaves as if
your screen  was <nrcols> columns  wide and will therefore print fewer
extra sloshes.  If  the screen is  actually  not  so wide it   is your
operating system's duty to handle this situation. Beware: <nrcols> can
be at most 256.

3. Andreas Prinz  also  asked how to  print  something  on the  screen
without moving  the  cursor position.  It is possible   to include the
control sequence `\b' in a string, which --  when printed -- moves the
cursor back one position. Similarly, the control  sequence `\c' at the
end of a string forces printing even if the string includes no newline
character. For example,

Print("for exemple\c");Lattice(SymmetricGroup(10));;Print("\b\b\b\b\ba\n");

prints   `for exemple', waits   quite  some  time and  then overwrites
`exemple' with `example'.

Hope this helps, Heiko Thei{\ss}en



From jean.michel@ens.fr Fri Oct 20 16:26:00 1995
Date:           Fri, 20 Oct 95 16:26:00 +0100 (MET)
From:           "Jean Michel" <jean.michel@ens.fr>
Subject:        Workshop on GAP internals?

Dear Gap-Forum,
I have had the idea described below, in relation with the
impending retirement of prof. Neubuser, and the expected
distribution of GAP developement over various sites when
this will occur.

There are presently only very few people outside of Aachen
who know enough about the internals of GAP to be able to make
improvements to the kernel or even just debug it. On the other
hand, there are quite a few people who are interested in GAP
development, have been involved in the development of packages
in the GAP language, and would be interested in participating
in future development of the kernel (e.g. myself). The problem
is the steep learning curve due to the lack of documentation
and/or teaching material about the C sources of the kernel.
It is to be hoped that such documentation will be written
before GAP development leaves Aachen (probably a lot
of work in perspective for the main developper, M.Schoenert).
In the meanwhile, I thought it would be a good thing if it was
possible to organize in Aachen sometime something like a
one-week workshop  on GAP internals, where interested people
could come and have a good start at learning how to hack
(properly) the kernel.

I talked briefly about this with prof. Neubuser during the DAG
day in Amiens, and he also thought it a good idea, and that
possibly next spring could be a good time for such a workshop.

What do other people think of this?

Jean MICHEL



From a.mathas@ic.ac.uk Fri Oct 20 19:30:00 1995
Date:           Fri, 20 Oct 95 19:30:00 +0100
From:           "Andrew Mathas" <a.mathas@ic.ac.uk>
Subject:        Re: Workshop on GAP internals?

#I talked briefly about this with prof. Neubuser during the DAG
#day in Amiens, and he also thought it a good idea, and that
#possibly next spring could be a good time for such a workshop.
#
#What do other people think of this?

Given the rate at which GAP is currently growing such a meeting would seem
to be not only a good idea but also necessary.

Another aspect of GAP programming which I think needs to be discussed is
the implementation of 'utility functions' which would be useful additions
to many of the existing GAP functions. In particular, I think that functions
SaveTo() and TeX() described below are needed. Currently such functions are
either non-existent, implemented on an ad hoc basis, or written by
individual users and so not publically available.

1. SaveTo(): At present there is no uniform way to save
a GAP data structure for future retrieval. The most common way around this
is to print the structure to a file; however, this is often very
inefficient to read back in (eg. polynomials, sparse matrices). The SaveTo()
handler might look like this:

 SaveTo:=function(arg)local save;
   save:=function(args)local a;
     for a in args do
       if IsRec(a) and IsBound(a.operations) and
           IsBound(a.operations.SaveTo)
       then a.operations.SaveTo(a);
       else Print(a);
       fi;
     od;
   end;

   if IsFunc(arg[1]) then arg[1](arg[2],  save(arg{[3..Length(arg)]}));
   else PrintTo(arg[1], save(arg{[2..Length(arg)]}));
   fi;
  end;

Thus, SaveTo("fred", x) and SaveTo(AppendTo, "fred", x) are both valid
function calls (each having the obvious effect), and x.operations.SaveTo()
would use the Print() statement throughout.

2. TeX(): Obviously useful. I have written TeX functions for printing
polynomials, elements of the Hecke algebras (from the Weyl package), and
some other things. I am happy to make these available; however in order to
implement these functions properly there should be a TeX() handling function
which calls x.operations.TeX(); it would look something like this:

  TeX:=function(arg) local a,i;
    for a in arg do
      if IsInt(a) or IsString(a) then Print(a);
      elif IsList(a) then for i in a do TeX(i); od;
      elif IsRec(a) and IsBound(a.operations) and IsBound(a.operations.TeX)
      then a.operations.TeX(a);
      else Print("*error*", "TeX(<a>), don't know how to TeX <a>\n");
      fi;
    od;
  end;

3. Other candidates are a Maple() function and any functions which are common
to many areas of mathematics, such as InnerProduct(), Induce() and so on.


Andrew Mathas



From aeb@win.tue.nl Sat Oct 21 02:08:00 1995
Date:           Sat, 21 Oct 95 02:08:00 +0100
From:           "Andries E. Brouwer" <aeb@win.tue.nl>
Subject:        Re: Workshop on GAP internals?

> lack of documentation and/or teaching material about
> the C sources of the kernel.

My experience is 1. that it is very difficult to keep detailed
descriptions of a large program accurate and up-to-date, and
2. that the GAP kernel is very easy to read - the source is
really self-documenting.
So, I don't think the situation is so bad.
I have difficulties imagining who would really profit from such
a workshop.

Andries



From pasec@can.nl Sat Oct 21 09:08:00 1995
Date:           Sat, 21 Oct 95 09:08:00 +0000 (GMT)
From:           "Dima Pasechnik" <pasec@can.nl>
Subject:        Re: Workshop on GAP internals?

Dear Forum,

   Date:           21 Oct 95 02:08 +0100
   From: A.E. Brouwer <aeb@win.tue.nl>

   > lack of documentation and/or teaching material about
   > the C sources of the kernel.

   My experience is 1. that it is very difficult to keep detailed
   descriptions of a large program accurate and up-to-date, and
   2. that the GAP kernel is very easy to read - the source is
   really self-documenting.
   So, I don't think the situation is so bad.
   I have difficulties imagining who would really profit from such
   a workshop.

   Andries

------------------------------------------------------------------------
While I agree with the fact that the GAP kernel is easy to read,
one would need to spend a lot of time in order to understand details of
how the things work there.

Certainly many not very experienced people interested in somewhat
deeper knowledge of mathematical software would benefit from such a
workshop, given that its emphasis is not only on "quick and dirty"
ways to hack GAP kernel.

Regards,
Dima
-----------------------------------------------------------------
Dmitrii V. Pasechnik
RIACA/CAN
419 Kruislaan
1098 VA Amsterdam
The Netherlands
phone: +31 20 560 8480
fax:   +31 20 560 8448
email: pasec@can.nl



From martin.schoenert@math.rwth-aachen.de Mon Oct 23 09:32:00 1995
Date:           Mon, 23 Oct 95 09:32:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Re: Rubik's Cube

John Pliam wrote in his article of 1995/10/12

                         I saw this on the Gap forum and was wondering what
    is the worst case minimum # of moves (diameter of the Cayley graph)?
    Does anyone know?   I have read claims of like 50?

    I have become interested in this again, because of applications to routing
    in parallel archectures (I actually found papers using the Schreier thm.
    in eng. journals :-)

I assume you mean God's algorithm for Rubik's Cube.  I.e., how many
quarter turns would God have to make to bring a state back to the solved
state in the worst case?

We know now that there are states (e.g. the superflip where all edges are
flipped and all corners are correct) that require at least 24 quarter
turns.  This was done basically as follows.  Enumerate all states that
are at most 11 quarter turns from the solved state.  Then enumerate all
states that are at most 11 quarter turns away from the superflip state.
Those two sets have no common element, so superflip is more than 22
quarter turns away from the solved state.  Since it is an even
permutation, any process for the superflip requires an even number of
quarter turns.  Thus superflip is at least 24 quarter turns away from the
solved state.  This was done by Jerry Bryan.  Michael Reid found a
process for the superflip that requires 24 quarter turns.

On the other hand we know an algorithm that requires at most 42 quarter
turns for any state.  This works by first bringing the state into the
subgroup H = < U, D, L^2, R^2, F^2, B^2 >, and then solving this state.
Both the coset space G / H and H were exhaustively searched (quite an
achievement).  This was done by Michael Reid.

The agreement seems to be that the true answer will be very close to 24.
So I don't think anybody is working on raising the lower bound.
I don't think anybody has an idea how to lower the upper bound much.

You can find out more about this and about the Cube in general by
joining the Cube-Lovers mailing list.  To subscribe send a message
to 'Cube-Lovers-Request@ai.mit.edu'.  To read older messages get the
archives from 'ftp.ai.mit.edu:/pub/cube-lovers/' or check out
'http://www.math.rwth-aachen.de:8000/LDFM/People/Martin_Schoenert_Private/Cube-Lovers/'.

Martin.

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



From ferrero@prmat.math.unipr.it Mon Oct 23 10:38:00 1995
Date:           Mon, 23 Oct 95 10:38:00 +0100
From:           "Giovanni Ferrero" <ferrero@prmat.math.unipr.it>
Subject:        Re: Workshop on GAP internals?

Yes, it is a very good idea. We had much pain to a very little touch
(useful only for us) to the GAP-source!



From sal@dcs.st-andrews.ac.uk Mon Oct 23 10:47:00 1995
Date:           Mon, 23 Oct 95 10:47:00 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        Re: Workshop on GAP internals?


Jean Michel proposed two things:

1) more documentation of the kernel
2) a workshop on "GAP internals"

I will take them one at a time:

1.

Documentation is an issue that is already being discussed as preparation of
GAP 4 and preparations for the move to St. Andrews get underway. The present
manual is an excellent reference manual, and we certainly intend that it
should continue. We are, however, considering a number of other areas that
should be addressed by documentation. Amongst these are:

a) Various tutorial manuals for users;
b) An "advanced" programming manual;
c) Coding standards for kernel, library and share package code;
d) Documentation for the internal interfaces, conventions and practices.

As Andries remarks, keeping documentation up-to-date is always a problem, and
it is certainly better to have sparse but accurate documentation, together
with well-commented code, than voluminous documents which are wrong.

We are very open to suggestions for the structure, format and content of new
GAP documentation, as well as offers of assistance.

2.

I can see two functions for a "GAP internals workshop".  Firstly, it would be
an opportunity for the GAP developers to provide "advanced" instruction and
guidance to the more experienced users and application developers. Some of us
have been lucky enough to spend time in Aachen getting individual support, but
a workshop might be a way to instruct more people more thoroughly for less
investment of the developers time. Secondly, a workshop would be an
opportunity to provide intensive feed-back. Andrew Mathas made a couple of
suggestions within this thread.

The question of timing is a rather delicate one. The basic shape of GAP 4 is
now set, but many details are still malleable. If the workshop is too early
then instruction given might be obsolete before the system is released, while
if it is too late, feedback could not be acted on (at least for version 4.1,
there will be more versions).

My provisional view (and I am quite happy to be persuaded otherwise) is that
the correct time for such a meeting is probably quite close to the release of
GAP 4.1, so that the instructional side of the workshop would have something
solid to work with. Such a meeting, featuring users with substantial GAP
applications and experience might also provide valuable beta-testing for the
new system. This leaves the feed-back question slightly adrift, but (a) there
will be releases after 4.1 and (b) there is always the GAP-forum.

        Steve Linton



From jean.michel@ens.fr Mon Oct 23 15:58:00 1995
Date:           Mon, 23 Oct 95 15:58:00 +0100 (MET)
From:           "Jean Michel" <jean.michel@ens.fr>
Subject:        Re: Workshop on GAP internals?

Steve Linton makes a lot of remarks with which I agree completely
on the state of GAP documentation and on the potential usefulness
of a workshop on GAP internals, then ends with

>>...
>> My provisional view (and I am quite happy to be persuaded otherwise) is that
>> the correct time for such a meeting is probably quite close to the release of
>> GAP 4.1, so that the instructional side of the workshop would have something
>> solid to work with.
>> ...

It seems to me that the intended public would have a thorough
knowledge of the GAP language and would not need too much
'hands-on' experience, so maybe as soon as the 4.xx kernel is stable
might be the right time (i.e. maybe we should not need to wait until
the GAP 3.xx libraries have been completely rewritten...)

   Jean MICHEL



From joachim.neubueser@math.rwth-aachen.de Tue Oct 24 10:33:00 1995
Date:           Tue, 24 Oct 95 10:33:00 +0100
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Re: Workshop on GAP internals?

Dear Colleagues,

In the Aachen GAP  team we have  also discussed Jean Michel's proposal
of a  workshop on GAP  and  are in  favour  of the  idea. We also have
followed the discussion on the proposal.  We think that some time next
Spring (about April, say) may be feasable, meeting the various aspects
that have been mentioned for consideration in the choice of the date.

We would like to wait  for possible further  comments before in a  few
days   we will  come forward  with  a  more detailed  proposal for the
organisation of  such a workshop.  We will then also  ask who might be
interested to attend before we start to plan the necessary logistics.

Kind regards   Joachim Neubueser



From sal@dcs.st-andrews.ac.uk Tue Oct 24 17:25:00 1995
Date:           Tue, 24 Oct 95 17:25:00 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        GAP references


Dear Forum,

I am compiling a GAP bibliography. I am interested in references to:

1) descriptions of research that used GAP (papers, conference procedings,
tech. reports, dissertations, etc.)

2) articles about GAP or articles about computational group theory in general
that mention GAP -- reviews, survey articles, etc.

3) anything else you think might be relevant or interesting.

Please send material to me directly, and I will make the collection available
for FTP and post the details to the Forum.

        Steve Linton



From charnes@osiris.cs.uow.edu.au Wed Oct 25 13:19:00 1995
Date:           Wed, 25 Oct 95 13:19:00 +1000
From:           "Chris Charnes" <charnes@osiris.cs.uow.edu.au>
Subject:        Re: GAP references

Steve, what is your email address (re GAP references)
C. Charnes



From ferrero@prmat.math.unipr.it Wed Oct 25 10:13:00 1995
Date:           Wed, 25 Oct 95 10:13:00 +0100
From:           "Giovanni Ferrero" <ferrero@prmat.math.unipr.it>
Subject:        Re: Workshop on GAP internals?

I think can send a my pupil, if Italy has sufficient money!:-)



From sal@dcs.st-andrews.ac.uk Wed Oct 25 08:57:00 1995
Date:           Wed, 25 Oct 95 08:57:00 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        Re: GAP references

Charles Charnes asked, very reasonably:

> Steve, what is your email address (re GAP references)

I hadn't realised how thorough the GAP-forum remailer was in stripping off
addresses.

Please send references to

sal@dcs.st-and.ac.uk

        Thanks
                Steve Linton



From sal@dcs.st-andrews.ac.uk Wed Oct 25 08:57:00 1995
Date:           Wed, 25 Oct 95 08:57:00 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        Re: GAP references

Charles Charnes asked, very reasonably:

> Steve, what is your email address (re GAP references)

I hadn't realised how thorough the GAP-forum remailer was in stripping off
addresses.

Please send references to

sal@dcs.st-and.ac.uk

        Thanks
                Steve Linton



From goetz@dcs.st-andrews.ac.uk Tue Oct 24 18:07:00 1995
Date:           Tue, 24 Oct 95 18:07:00 +0000
From:           "Goetz Pfeiffer" <goetz@dcs.st-andrews.ac.uk>
Subject:        Re: GAP references

Hi Steve,

here is the part of my bibliography which refers to GAP. (That is of
course: evrything :-)  You will receive (hopefully) a separate mail
from BIDS, which I caused to list all articles that cite the GAP manual.

Goetz.

--8<-------------------------------------------------------------------------
@string{AdvMath = "Adv. Math."}
@string{BayreuMS = "Bayreuther Math. Schr."}
@string{JAlg = "J. Algebra"}
@string{Manuscr = "Manuscripta Math."}

@string{RWTH = "RWTH Aachen"}
@string{LDfM = "Lehrstuhl D f{\"u}r Mathematik, " # RWTH}
@string{UHeidel = "Universit{\"a}t Heidelberg"}
@string{IWR = "Interdisziplin{\"a}res Zentrum f{\"u}r wissenschaftliches
                  Rechnen der " # UHeidel}

@article{GePf92,
author = "Meinolf Geck  and G{\"o}tz Pfeiffer",
title = "Unipotent Characters of the {C}hevalley Groups ${D}_4(q)$, $q$ odd",
journal = Manuscr,
volume = 76,
pages = "281--304",
year =  1992,
}

@article{GePf93,
author = "Meinolf Geck and G{\"o}tz Pfeiffer",
title = "On the Irreducible Characters of {H}ecke Algebras",
journal = AdvMath,
year = 1993,
volume = 102,
pages = "79--94",
}

@techreport{chevie,
author = "Meinolf Geck and Gerhard Hi{\ss} and Frank
                  L{\"u}beck and Gunter Malle and G{\"o}tz Pfeiffer,
title = "{\sf CHEVIE} -- {G}eneric {C}haracter {T}ables of {F}inite
                  Groups of {L}ie {T}ype, {H}ecke {A}lgebras and
                  {W}eyl {G}roups",
type = "Preprint",
number = "93-62",
month = Nov,
year = 1993,
institution = IWR,
}

@techreport{chevie2,
author = "Meinolf Geck and Gerhard Hi{\ss} and Frank
                  L{\"u}beck and Gunter Malle and G{\"o}tz Pfeiffer,
title = "{\sf CHEVIE} -- {A} system for computing and processing
                  generic character tables",
type = "Preprint",
number = "95-05",
month = Jan,
year = 1995,
institution = IWR,
}

@MastersThesis{Pfeiffer91,
  author = Pfeiffer,
  title = "Von {P}ermutationscharakteren und {M}arkentafeln",
  school = LDfM,
  year = 1991,
  month = Jan,
  type = "Diplomarbeit"
}

@article{Pfeiffer94a,
author = "G{\"o}tz Pfeiffer",
title = "Character Tables of {W}eyl Groups in {{\sf GAP}}",
journal = BayreuMS,
volume = 47,
pages = "165--222",
year = 1994,
}

@article{Pfeiffer94b,
author = "G{\"o}tz Pfeiffer",
title = "Young Characters on {C}oxeter Basis Elements of {I}wahori--{H}ecke
   Algebras and a {M}urnaghan--{N}akayama Formula",
journal = JAlg,
volume = 168,
pages = "525--535",
year = 1994,
}

@Book{PfDiss,
  author =       "G{\"o}tz Pfeiffer",
  title =        "Charakterwerte von {I}wahori-{H}ecke-{A}lgebren von
                  klassischem {T}yp",
  publisher =    "Verlag der Augustinus Buchhandlung, Aachen",
  year =         1995,
  volume =       14,
  series =    "Aachener {Beitr\"age} zur Mathematik"
}

@Proceedings{Pfeiffer95a,
  author = "G{\"o}tz Pfeiffer",
  title =        "Character Values of Iwahori-Hecke algebras of type B",
  year =         1995,
  note =         "in print"
}

@MastersThesis{Pfeiffer91,
  author = Pfeiffer,
  title = "Von {P}ermutationscharakteren und {M}arkentafeln",
  school = LDfM,
  year = 1991,
  month = Jan,
  type = "Diplomarbeit"
}

@Misc{Pfeiffer95b,
  author = Pfeiffer,
  title = "The subgroups of {$M_{24}$} or {H}ow to compute a table of marks",
  howpublished = "in preparation"
}



From conder@mat.auckland.ac.nz Wed Oct 25 11:48:00 1995
Date:           Wed, 25 Oct 95 11:48:00 +1300
From:           "Marston Conder" <conder@mat.auckland.ac.nz>
Subject:        Re: GAP references



Hi Steve

The following research articles refer to actual or potential use of GAP:

Marston Conder,  Hexagon-free subgraphs of hypercubes,
J. Graph Theory  17 (1993), 477-479.

Marston Conder,  Regular maps with small parameters,
J. Australian Math. Society  57 (1994), 103-112.

Marston Conder & John McKay,  Markings of the Golay code,  preprint.

Cheers
Marston



From goetz@dcs.st-andrews.ac.uk Wed Oct 25 13:02:00 1995
Date:           Wed, 25 Oct 95 13:02:00 +0000
From:           "Goetz Pfeiffer" <goetz@dcs.st-andrews.ac.uk>
Subject:        Re: GAP references

Dear Forum,

sorry for wasting bandwidth by sending my last message to forum.  I
know: I should have mailed this explicitely to

   sal@cs.st-and.ac.uk

instead of just pushing the reply button.

Goetz.
-----------------------------------------------------------------------------
Goetz Pfeiffer (goetz@cs.st-and.ac.uk)  http://gregory.cs.st-and.ac.uk/~goetz
Department of Mathematics, University of St Andrews, Fife KY16 9SS, Scotland.
-----------------------------------------------------------------------------



From frank.celler@math.rwth-aachen.de Mon Oct 30 11:22:00 1995
Date:           Mon, 30 Oct 95 11:22:00 +0100 (MET)
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        XGAP 1 Release 3

Dear GAP Forum,

a new version of XGAP is available from our ftp server.

What's new in this version? Basically everything mentioned under "What
is XGAP?"  below plus  a manual, which  can either be printed as stand
alone version or  as part of the GAP  manual, details on how  to print
the manual can be  found  in the file  "gap3r4p2/pkg/xgap/INSTALL.x11"
contained in the archive "xgap1r3.zoo". The stand alone manual is also
avaiable via ftp.

best wishes
  Frank

=============================================================================
What is XGAP?
-------------

XGAP is a graphical user interface for GAP, it extends the GAP library
with functions  dealing with graphic sheets  and objects.  Using these
functions it also supplies a graphical interface for investigating the
subgroup lattice of a  group, giving you  easy access to the low index
subgroups,  prime quotient  and  Reidemeister-Schreier algorithms  and
many other GAP functions for groups and subgroups.   At the moment the
only supported window system is X-Windows X11R5 (and higher), however,
programs using the XGAP library functions will  run on other platforms
as soon as XGAP is  available on these.   We plan to release a Windows
3.11 or Windows 95 version in the near future.

I was  told that XGAP  will   also run under  SUN's  OpenWindows.   It
doesn't however compile under OpenWindows.  If any OpenWindow guru can
fix this, please send me a patch.

Where to get XGAP?
------------------

You can get XGAP from  "ftp.math.rwth-aachen.de", the source code  and
binaries are in the directory "/pub/incoming":

  xgap1r3.zoo (333912 Bytes) - this archive contains the C source code
      and the GAP library files necessary to compile and run XGAP.

  xgap1r3-dvi.zoo (44696 Bytes) - this archive contains the DVI file
      of the manual.

  xgap1r3-dec-alpha-osf1-x11r5.zoo (820751 Bytes) - this archive
      contains the executable for a DECalpha running OSF1 and X11R5.

  xgap1r3-dec-mips-ultrix42-x11r5.zoo (434616 Bytes) - this archive
      contains the executable for a DECstation running Ultrix 4.2 and
      X11R5.

  xgap1r3-hp-hppa1.1-hpux9-x11r5.zoo (410380 Bytes) - this archive
      contains the executable for a HP9000/700 running HPUX9 and
      X11R5.

  xgap1r3-sun-sparc-sunos412-x11r5.zoo (464671 Bytes) - this archive
      contains the executable for a SUN SPARCstation running SunOS
      4.1.2 and X11R5, I assume that it also works under OpenWindows,
      any feedback welcome.

How to compile XGAP?
--------------------

Instructions can be found in the file "gap3r4p?/pkg/xgap/INSTALL.x11".
You need at least a CC compiler, X11R5 & Athena Widgets, and a running
version of GAP 3.4.



From sarah.rees@newcastle.ac.uk Mon Oct 30 22:41:00 1995
Date:           Mon, 30 Oct 95 22:41:00 +0000 (GMT)
From:           "Sarah Rees" <sarah.rees@newcastle.ac.uk>
Subject:        Re:  XGAP 1 Release 3

Hi Frank, I'm sorry, you've released it and I haven't tested it for you
yet. I feel bad about that, and am sorry. I do actually have it now, but I
realise it's taken me a long time. I am doing a huge amount of teaching at the
moment, and I simply don't have any time. It'll get better soon, and then
I'll give xgap a proper test,
   Sarah



From jmccarro@mercator.math.uwaterloo.ca Tue Oct 31 03:03:00 1995
Date:           Tue, 31 Oct 95 03:03:00 -0500
From:           "James McCarron" <jmccarro@mercator.math.uwaterloo.ca>
Subject:        Re: XGAP 1 Release 3

>
> I was  told that XGAP  will   also run under  SUN's  OpenWindows.   It
> doesn't however compile under OpenWindows.  If any OpenWindow guru can
> fix this, please send me a patch.

Well, it compiled just fine for me this afternoon. There were no problems
with any of the graphics stuff. I am using Solaris2.3/OpenWindows3.3.
The only thing is that, Solaris does not provide 'wait3', but only the
'waitpid', so you must link with the BSD libraries by adding
-L/usr/ucblib -R/usr/ucblib -lucb to the linking step of the compilation.
This is (so I am led to understand) not the preferred solution, but
it works; later, I'll try to figure out how to use 'waitpid' as the
Solaris documentation suggests.
Anyway, although I've just installed it today, so far,
it looks impressive! Very nice! Thank you!

James
__
Dr. James McCarron
Department of Pure Mathematics // University of Waterloo
Waterloo, Ontario CANADA?
<jmccarron@{barrow,excalibur,jeeves,mercator}.uwaterloo.ca>



From pbrown@math.berkeley.edu Wed Nov  1 20:32:00 1995
Date:           Wed, 01 Nov 95 20:32:00 -0800
From:           "Paul Robert Brown" <pbrown@math.berkeley.edu>
Subject:        LowIndexSubgroupsFpGroup


The GAP command "LowIndexSubgroupsFpGroup()" could be improved by adding
an argument for a range of subgroup indices instead of the current
maximum integer n implying a range of [1..n]. (This is a feature of the
equivalent magma command, for instance.)

Has anyone attempted this patch?

I'm also interested if anyone out there has coset enumeration routines
written in C, as I'm only interested in checking for the existence of
representations of a given degree.

Thanks in advance.

Paul Brown



From sal@dcs.st-andrews.ac.uk Fri Nov  3 11:28:00 1995
Date:           Fri, 03 Nov 95 11:28:00 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        GAP references


Dear all,

References have been pouring in and I am afraid I haven't had time to
acknowledge them all. My thanks to everyone who has sent material in so far.
Please keep them coming.

        Steve



From martin.schoenert@math.rwth-aachen.de Fri Nov  3 15:26:00 1995
Date:           Fri, 03 Nov 95 15:26:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: LowIndexSubgroupsFpGroup

Paul Robert Brown wrote in his e-mail message of 1995/11/01

    The GAP command "LowIndexSubgroupsFpGroup()" could be improved by adding
    an argument for a range of subgroup indices instead of the current
    maximum integer n implying a range of [1..n]. (This is a feature of the
    equivalent magma command, for instance.)

The time taken by the 'LowIndexSubgroupsFpGroup' function depends mostly
on the largest index considered.  That means that excluding smaller
indices will not decrease the time taken.  I think the same is true for
the corresponding Magma command, but I have never tried it.  Anyhow, that
means that it is just as fast to compute all the subgroups up to the
largest index and throwing out the ones whose index does not lie in the
interesting range afterwards.  This is the reason why I never bothered
to add this feature.

He continued

    I'm also interested if anyone out there has coset enumeration routines
    written in C, as I'm only interested in checking for the existence of
    representations of a given degree.

I don't see what the fact that you are only interested in checking for
the existence of representations of a given degree has to do with whether
a program to look for them is written in C or in GAP.  Besides what
exactely do you mean by ``coset enumeration routines''?  A program to
compute the index for a given subgroup or a program to find all subgroups
up to a given index?  Write me and I see whether I can help you.

Martin.

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



From ganief@math.unp.ac.za Mon Nov  6 08:46:42 1995
Date:           Mon, 06 Nov 95 08:46:42 +0200
From:           "Shahiem Ganief" <ganief@math.unp.ac.za>
Subject:        Re: MeatAxe on pc

Dear Sir

We are having problems running MeatAxe from a personel computer, and
your help will be very much appreciated.

We are runnig GAP3R4P2 (dos version) perfectly from a 486 computer.
However, when I call up the function 'RequirePackage("meataxe") the
following appears
      Invalid switch - /000069
      #I The MeatAxe share library functions are available now.
      #I All files will be placed in the directory
      #I      'c:\DOS/000069'
      #I Use 'MeatAxe.SetDirectory( <path> )' if you want to change.

The problem is that this file does not exist. If I create this file
(manually), MeatAxe then places files in ile (manually) MeatAxe place
files in the directory 'c:\dos/a00069'.  I tried to change the path
using the function "MeatAxe.SetDirectory( <path> )" without sucess.
Can you get me out of this hole?

Thanking you in anticipation.
Shahiem Ganief



From kiechle@mathematik.tu-muenchen.de Fri Nov 10 15:11:39 1995
Date:           Fri, 10 Nov 95 15:11:39 +0100
From:           "Kiechle Hubert" <kiechle@mathematik.tu-muenchen.de>
Subject:        customizing Emacs (gap.el)

Hi GAPers,

has anybody ever customized Emacs to write gap code? Is there anything
like  gap.el(c)? I know that I could modify a  c++.el  or  pascal.el
to do the job, but I'm hoping, it's already out there.

So long

--

Hubert Kiechle

Mathematisches Institut
Technischen Universit"at M"unchen
D-80290 M"unchen

Tel.: +49 89 2105 8288

e-mail: kiechle@mathematik.tu-muenchen.de



From sal@dcs.st-andrews.ac.uk Wed Nov 15 12:34:09 1995
Date:           Wed, 15 Nov 95 12:34:09 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        Re: customizing Emacs (gap.el)

Emacs modes for editting GAP code, and for running GAP in an EMACS window were
supplied by Michael Smith of the ANU in Canberra and are included in the GAP
distribution in the /etc directory.

        Steve Linton



From werner.nickel@math.rwth-aachen.de Wed Nov 15 16:04:00 1995
Date:           Wed, 15 Nov 95 16:04:00 +0100 (MET)
From:           "Werner Nickel" <Werner.Nickel@Math.RWTH-Aachen.DE>
Subject:        Re: customizing Emacs (gap.el)

Hubert Kiechle asked the following:

> has anybody ever customized Emacs to write gap code? Is there anything
> like  gap.el(c)? I know that I could modify a  c++.el  or  pascal.el
> to do the job, but I'm hoping, it's already out there.

In addition to Steve's answer I'd like to mention that the newest
version of Michael's GAP mode for emacs can be obtained via anonymous
ftp from
    ftp.math.rwth-aachen.de:/pub/incoming/

Get the files
    emacs-gap-mode-1.96.tar.gz
    emacs-gap-mode.readme.

With kind regards, Werner Nickel.



From mas023@bangor.ac.uk Fri Nov  3 18:55:19 1995
Date:           Fri, 03 Nov 95 18:55:19 +0000
From:           "Chris Wensley" <mas023@bangor.ac.uk>
Subject:        Copy & SemidirectProduct

I have had some trouble comparing automorphisms of SemidirectProducts of
some small permutation groups.  Eventually it appeared that the problem
arose due to the use of Copy.  I have not very familiar with the use of
Copy, but this particular problem does nor arise with permutation groups
as far as I can see.
Any assistance would be appreciated.  A log file follows.

( By the way: should I be using "Copy" anyway? :-
( If I define a function and wish to attach a local variable to the
( parameter as an extra field, the following appear to work:
(     test := function( x )
(         local y;
(         ...;  y:=...;
(         x.test := y;          OR:      x.test := Copy( y );
(         return y;
(     end;
( I "feel" that I ought to use Copy, in case the next call of the
( function overwrites the value of y.  What is good practice here?

Chris Wensley (mas023@bangor.ac.uk)
==================================================================

gap> # No problem with permutation groups:
gap> G := Group( (1,2), (2,3) );;  G.name:="G";;
gap> eG := Elements(G);
[ (), (2,3), (1,2), (1,2,3), (1,3,2), (1,3) ]
gap> H := Copy(G);;  eH := Elements(H);;
gap> G=H;
true
gap> eH[3] in eG;
true

gap> # construct a SemidirectProduct:
gap> c2 := Subgroup( G, [(1,2)]);;    c2.name := "c2";;
gap> c3 := Subgroup( G, [(1,2,3)]);;  c3.name := "c3";;
gap> id := IdentityMapping(c2);;
gap> S := SemidirectProduct( c2, id, c3 );  S.name:="S";;
Group( SemidirectProductElement( (1,2), (1,2), () ),
       SemidirectProductElement( (), (), (1,2,3) ) )
gap> T := Copy( S );;  T.name := "T";;
gap> eS := Elements( S );
[ SemidirectProductElement( (), (), () ),
  SemidirectProductElement( (), (), (1,2,3) ),
  SemidirectProductElement( (), (), (1,3,2) ),
  SemidirectProductElement( (1,2), (1,2), () ),
  SemidirectProductElement( (1,2), (1,2), (1,2,3) ),
  SemidirectProductElement( (1,2), (1,2), (1,3,2) ) ]
gap> eT := Elements(T);;

gap> # Now try some comparisons:
gap> S=T;
Error, sorry, cannot compare the infinite domains <D> and <E> in
<rec1> = <rec2> called from
<rec1> = <rec2> called from
<rec1> = <rec2> called from
main loop
brk> D;
GroupElements
brk> E;
GroupElements
brk> quit;

gap> eS[4] in eT;
Error, sorry, cannot compare the infinite domains <D> and <E> in
<rec1> = <rec2> called from
<rec1> = <rec2> called from
main loop
brk> quit;



From thomas.breuer@math.rwth-aachen.de Wed Nov 15 17:52:00 1995
Date:           Wed, 15 Nov 95 17:52:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        Re: Re: MeatAxe on pc

Dear GAP-Forum,

Shahiem Ganief asked

> We are runnig GAP3r4P2 (dos version) perfectly from a 486 computer.
> However, when I call up the function 'RequirePackage("meataxe") the
> following appears
>       Invalid switch - /000069
>       #I The MeatAxe share library functions are available now.
>       #I All files will be placed in the directory
>       #I      'c:\DOS/000069'
>       #I Use 'MeatAxe.SetDirectory( <path> )' if you want to change.
>
> The problem is that this file does not exist. If I create this file (manually),
> MeatAxe then places files in 'c:\dos/a00069'.  I tried to change the path
> using the function "MeatAxe.SetDirectory( ,path>)" without sucess.
> Can you get me out of this hole?

It would be possible to change the interface between GAP and the 'meataxe'
package such that one could work with the package under DOS.
However, the typical use of the 'meataxe' package involves a lot of calls
to the C functions of the package.
Under DOS, this would work very slow, because for each call of an external
program from GAP the whole GAP must be swapped to disc.

So instead one should either
- use the equivalent (but slower) GAP functions for matrix calculations
  (multiplication, transposing, null space computation, ...),
  and use the 'smash' package for module calculations.
or
- use the standalone functions without GAP; if one wants to read results
  into GAP in the end, one can use the '-G' option of the C functions to
  produce GAP readable output.

Kind regards
Thomas Breuer



From quitte@knuth.univ-poitiers.fr Wed Nov 15 18:40:53 1995
Date:           Wed, 15 Nov 95 18:40:53 NFT
From:           "Claude Quitte" <quitte@knuth.univ-poitiers.fr>
Subject:        GAP problem

Hello,

Thanks for your system G.A.P. !

I have a problem with the function "IsInjective" (I use the version 3,
release 4, 18 May 95). Here the exact GAP file with its execution.
I don't know the best way to send a report problem so I put the 2 files
(the source file + execution). Is there a good way to transmit reports ??

Best regards.

------------------------------- cut here -----------
LogTo("bug1.gap.result") ;

# Pour les matrices a coefficients dans un corps premier
pretty := function(M)
   local Copy_M, nm, n, m, i, j ;
   Copy_M := Copy(M) ;
   nm := DimensionsMat(Copy_M) ;
   n := nm[1] ; m := nm[2] ;
   for i in [1..n] do
      for j in [1..m] do
         Copy_M[i][j] := IntFFE(Copy_M[i][j]) ;
      od ;
   od ;
   return Copy_M ;
end ;

q := 5 ;
GL2Fq := GeneralLinearGroup(2, q) ;
for g in GL2Fq.generators do Print(pretty(g), "\n") ; od ;
Size(GL2Fq) ;
# h := generateur de Fq-{0}
h := Z(q) * [[1, 0], [0, 1]] ;; pretty(h) ;
Order(GL2Fq, h) ;

# C := centre de GL(2,Fq)
C := Subgroup(GL2Fq, [h]) ; C.name := "C" ;
Size(C) ;
C = Centre(GL2Fq) ;

# PGL2(Fq) = GL2(Fq)/centre
PGL2Fq := GL2Fq / C ;  PGL2Fq.name := "PGL2Fq" ;
Size(PGL2Fq) ;

# l'application canonique class : GL2Fq -> PGL2Fq
class := function(x) return FactorGroupElement(C, x) ; end ;

# sous-groupe K de Jean-Louis d'ordre 24
f := class((Z(q)^0 * [[1, 1], [2, 3]])) ;
of := Order(PGL2Fq, f) ;
g := class((Z(q)^0 * [[1, 3], [3, 1]])) ;
og := Order(PGL2Fq, g) ;
K := Subgroup(PGL2Fq, [f, g]) ; K.name := "K" ;
Size(K) ;

K_Left_Cosets := LeftCosets(PGL2Fq, K) ;
Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(PGL2Fq, K_Left_Cosets, OnLeft) ;
perm := OperationHomomorphism(PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;

IsSurjective(perm) ;

# Probleme GAP : IsInjective(perm) provoque une erreur
IsInjective(perm) ;

LogTo() ;

---------- and the execution ------------------------------------------

gap>
gap> # Pour les matrices a coefficients dans un corps premier
gap> pretty := function(M)
>    local Copy_M, nm, n, m, i, j ;
>    Copy_M := Copy(M) ;
>    nm := DimensionsMat(Copy_M) ;
>    n := nm[1] ; m := nm[2] ;
>    for i in [1..n] do
>       for j in [1..m] do
>          Copy_M[i][j] := IntFFE(Copy_M[i][j]) ;
>       od ;
>    od ;
>    return Copy_M ;
> end ;
function ( M ) ... end
gap>
gap> q := 5 ;
5
gap> GL2Fq := GeneralLinearGroup(2, q) ;
GL(2,5)
gap> for g in GL2Fq.generators do Print(pretty(g), "\n") ; od ;
[ [ 2, 0 ], [ 0, 1 ] ]
[ [ 4, 1 ], [ 4, 0 ] ]
gap> Size(GL2Fq) ;
480
gap> # h := generateur de Fq-{0}
gap> h := Z(q) * [[1, 0], [0, 1]] ;; pretty(h) ;
[ [ 2, 0 ], [ 0, 2 ] ]
gap> Order(GL2Fq, h) ;
4
gap>
gap> # C := centre de GL(2,Fq)
gap> C := Subgroup(GL2Fq, [h]) ; C.name := "C" ;
Subgroup( GL(2,5), [ [ [ Z(5), 0*Z(5) ], [ 0*Z(5), Z(5) ] ] ] )
"C"
gap> Size(C) ;
4
gap> C = Centre(GL2Fq) ;
true
gap>
gap> # PGL2(Fq) = GL2(Fq)/centre
gap> PGL2Fq := GL2Fq / C ;  PGL2Fq.name := "PGL2Fq" ;
(GL(2,5) / C)
"PGL2Fq"
gap> Size(PGL2Fq) ;
120
gap>
gap> # l'application canonique class : GL2Fq -> PGL2Fq
gap> class := function(x) return FactorGroupElement(C, x) ; end ;
function ( x ) ... end
gap>
gap> # sous-groupe K de Jean-Louis d'ordre 24
gap> f := class((Z(q)^0 * [[1, 1], [2, 3]])) ;
FactorGroupElement( C, [ [ Z(5)^3, Z(5)^3 ], [ Z(5)^0, Z(5)^2 ] ] )
gap> of := Order(PGL2Fq, f) ;
3
gap> g := class((Z(q)^0 * [[1, 3], [3, 1]])) ;
FactorGroupElement( C, [ [ Z(5)^2, Z(5) ], [ Z(5), Z(5)^2 ] ] )
gap> og := Order(PGL2Fq, g) ;
4
gap> K := Subgroup(PGL2Fq, [f, g]) ; K.name := "K" ;
Subgroup( (GL(2,5) / C),
[ FactorGroupElement( C, [ [ Z(5)^3, Z(5)^3 ], [ Z(5)^0, Z(5)^2 ] ] ),
  FactorGroupElement( C, [ [ Z(5)^2, Z(5) ], [ Z(5), Z(5)^2 ] ] ) ] )
"K"
gap> Size(K) ;
24
gap>
gap> K_Left_Cosets := LeftCosets(PGL2Fq, K) ;
[ (FactorGroupElement( C, [ [ Z(5)^0, 0*Z(5) ], [ 0*Z(5), Z(5)^0 ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5)^2 ], [ Z(5)^0, Z(5)^2 ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5) ], [ Z(5)^0, Z(5)^2 ] ] )*K),
  (FactorGroupElement( C, [ [ Z(5)^2, Z(5)^0 ], [ Z(5)^2, 0*Z(5) ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5)^0 ], [ Z(5)^0, Z(5)^2 ] ] )*K) ]
gap> Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(PGL2Fq, K_Left_Cosets, OnLeft) ;
Group( (2,4,5,3), (1,4,2) )
gap> perm := OperationHomomorphism(PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;
OperationHomomorphism( (GL(2,5) / C), Group( (2,4,5,3), (1,4,2) ) )
gap>
gap> IsSurjective(perm) ;
true
gap>
gap> # Probleme GAP : IsInjective(perm) provoque une erreur
gap> IsInjective(perm) ;
Error, power of <c> and <d> is not defined in
<rec1> ^ <rec2> called from
G.operations.Core( G, U ) called from
Core( hom.source, Stabilizer( hom.source, orb[1], hom.range.operation.
    operation ) ) called from
fun( i ) called from
List( Orbits( hom.source, hom.range.operation.domain, hom.range.operation.
    operation ), function ( orb ) ... end ) called from
...
brk> quit ;
gap>
gap> LogTo() ;
-----------------------------------------------------------

Best regards.

--
Claude Quitte
Dept de Mathematiques
40 Av du recteur Pineau
86022 Poitiers Cedex FRANCE
E-mail Internet : quitte@knuth.univ-poitiers.fr
Fax : 33-49-45-40-10



From heiko.theissen@math.rwth-aachen.de Thu Nov 16 08:40:00 1995
Date:           Thu, 16 Nov 95 08:40:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: Copy

Dear GAP-Forum,

Chris Wensley  has reported a  problem that occurs  when one  tries to
compare a semidirect product with a `Copy' of itself.

DIAGNOSIS:

In fact, the same problem occurs  even if one  tries to compare just a
semidirect  product element with a  copy  of itself. Such elements are
represented by records which contain an entry `.domain'. This entry is
set to `GroupElements'.

When  you compare  two such records,    GAP firsts checks whether  the
`.domain' entries are equal, i.e.,  it compares the domains. Comparing
`GroupElements'  with  itself should   be  no problem  since identical
objects are always equal in GAP. Unfortunately, since `Copy' was used,
the two instances of `GroupElements' are no longer identical (i.e. are
no longer stored in the same place in memory),  and so GAP has to give
up since it cannot compare infinite domains.

gap> GroupElements = Permutations;
Error, sorry, cannot compare the infinite domains <D> and <E> in
<rec1> = <rec2> called from
main loop
gap> GroupElements = Copy( GroupElements );
Error, sorry, cannot compare the infinite domains <D> and <E> in
<rec1> = <rec2> called from
main loop

THERAPY:

Avoid `Copy'.

When you declare a local variable inside a GAP function, it is created
*anew*  every time the function  is called. So  you do not have to use
`Copy' when you  assign the value of  a local variable to a  non-local
variable.

In the example

     test := function( x )
         local y;
         ...;  y:=...;
         x.test := y;          OR:      x.test := Copy( y );
         return y;
     end;

the <y> is  simply forgotten after the function  has been executed and
its former value is  only kept in <x.test>. So  no `Copy'  is required
here.

You should  be aware that an assignment   like `y :=  ...' can *never*
have side-effects  on  variables other  than <y>. Such  an  assignment
makes <y> point to  a new value,  but it does  *not* overwrite the old
value, and all other variables  that may also  have pointed to the old
value will still point there. Only if  the left hand  side of the `:='
is a record component or  a list entry,  the assignment *changes*  the
corresponding record or list, and then *all* variables that pointed to
the same record or list will be affected.

Hope this helps, Heiko Thei{\ss}en



From heiko.theissen@math.rwth-aachen.de Thu Nov 16 12:30:00 1995
Date:           Thu, 16 Nov 95 12:30:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: Problem with `IsInjective'

Dear GAP-Forum,

Claude  Quitte has reported an error  that occurs  inside the code for
`IsInjective', when a subgroup <U> is conjugated by an element <g> for
the  calculation of the   core of <U>. This error   occurs if <U> is a
factor group (in  the reported example  `GL(2,5)/C') and  <g> a factor
group  element, but a  similar error would occur  if <g> was a generic
(i.e., home-grown) group element.

DIAGNOSIS:

GAP objects like <U> and <g>  have a so-called operations record which
comprises all the functions (like `Size') that  are applicable to such
an object.  Since both   <U> and <g>  have  a  `^'-component in  their
operations record,  GAP choses the component in  the right operand <g>
when evaluating the expression `U ^ g', i.e.,  this is translated into
`g.operations.\^( U, g )'.

Unfortunately, the exponentiation function for (factor) group elements
(like  <g>)  does not consider   the  case ``power  of  group by group
element'', this case is only dealt with by the exponentiation function
for (factor) groups. This  means that `U.operations.\^(  U, g )' would
work, but because of the rule stated above, it will never be selected.
This is  certainly a  bug caused  by  insufficient organisation of the
library.

THERAPY:

In order to make things work for factor group elements, you would have
to    modify  the  library     file `grpcoset.g'.  In    the  function
`FactorGroupElementOps.\^', replace line  1621 (the `Error' statement)
with:

        return c.operations.\^( c, d );

If you want to  fix the bug   for generic group elements, replace  the
function `GroupElementOps.\^' in `grpelms.g', line 155ff. with:

GroupElementOps.\^ := function( a, b )
    if IsGroup( a )  then
        return a.operations.\^( a, b );
    else
        Error("no default method to multiply generic group elements");
    fi;
end;

Sorry for any inconvenience, Heiko Thei{\ss}en



From martin.schoenert@math.rwth-aachen.de Thu Nov 16 19:40:00 1995
Date:           Thu, 16 Nov 95 19:40:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Problems with GAP Forum, FTP, and WWW

Dear GAP forum readers,

About a week ago one of our disks crashed.  It was the disk on which the
GAP forum stuff, the 'ftp' software, and the WWW documents were stored.
Unfortunately we had no recent backup of this disk.

The GAP forum should be working again.  However, I had to reconstruct the
subscribers list from a copy of 95/10/16, making recent changes by hand.
I'm fairly certain that I haven't missed any subscription requests.
But it might be that I accidentally missed some unsubscription requests.
So if you unsubscribed after 95/10/16 and now receive this message,
please don't be mad at me, simply unsubscribe again.  I think I resend
all messages that came when the GAP forum was down (resp. answered one
message that was not of general interest), but if you are still looking
for a message you posted in the last week, write me.

The 'ftp' software for GAP 3.4.2 is back in place.  However, we lost
everything that went to '/pub/incoming/' since 95/02/26.  If you placed
stuff in there since 95/02/26, could you please 'ftp' it again.  (Or even
better if you recently downloaded all the stuff from '/pub/incoming/',
could you please make it available to us).

The WWW documents are gone for good.  It will take some time to make all
the documents again.  When the WWW server is running again I will write
a short notice to the GAP forum.

Sorry for the inconvenience.

Martin.

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



From quitte@knuth.univ-poitiers.fr Sat Nov 18 10:21:51 1995
Date:           Sat, 18 Nov 95 10:21:51 NFT
From:           "Claude Quitte" <quitte@knuth.univ-poitiers.fr>
Subject:        PreImagesRepresentative

Here a problem with the function "PreImagesRepresentatives" wich
returns "false" instead of an antecedent (which exists !).


--------------- the gap source ---------------------------
LogTo("bug2.gap.result") ;

# Pour les matrices a coefficients dans un corps premier
pretty := function(M)
   local Copy_M, nm, n, m, i, j ;
   Copy_M := Copy(M) ;
   nm := DimensionsMat(Copy_M) ;
   n := nm[1] ; m := nm[2] ;
   for i in [1..n] do
      for j in [1..m] do
         Copy_M[i][j] := IntFFE(Copy_M[i][j]) ;
      od ;
   od ;
   return Copy_M ;
end ;

q := 5 ;
GL2Fq := GeneralLinearGroup(2, q) ;
for g in GL2Fq.generators do Print(pretty(g), "\n") ; od ;
Size(GL2Fq) ;
# h := generateur de Fq-{0}
h := Z(q) * [[1, 0], [0, 1]] ;; pretty(h) ;
Order(GL2Fq, h) ;

# C := centre de GL(2,Fq)
C := Subgroup(GL2Fq, [h]) ; C.name := "C" ;
Size(C) ;
C = Centre(GL2Fq) ;

# PGL2(Fq) = GL2(Fq)/centre
PGL2Fq := GL2Fq / C ;  PGL2Fq.name := "PGL2Fq" ;
Size(PGL2Fq) ;

# l'application canonique class : GL2Fq -> PGL2Fq
class := function(x) return FactorGroupElement(C, x) ; end ;

# sous-groupe K de Jean-Louis d'ordre 24
f := class((Z(q)^0 * [[1, 1], [2, 3]])) ;
of := Order(PGL2Fq, f) ;
g := class((Z(q)^0 * [[1, 3], [3, 1]])) ;
og := Order(PGL2Fq, g) ;
K := Subgroup(PGL2Fq, [f, g]) ; K.name := "K" ;
Size(K) ;

K_Left_Cosets := LeftCosets(PGL2Fq, K) ;
Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(PGL2Fq, K_Left_Cosets, OnLeft) ;
perm := OperationHomomorphism(PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;

IsSurjective(perm) ;
PreImagesRepresentative(perm, (1,4,2)) ;
PreImagesRepresentative(perm, (1,4)) ;

LogTo() ;

------------------ the result ---------------------------------------------------

gap>
gap> # Pour les matrices a coefficients dans un corps premier
gap> pretty := function(M)
>    local Copy_M, nm, n, m, i, j ;
>    Copy_M := Copy(M) ;
>    nm := DimensionsMat(Copy_M) ;
>    n := nm[1] ; m := nm[2] ;
>    for i in [1..n] do
>       for j in [1..m] do
>          Copy_M[i][j] := IntFFE(Copy_M[i][j]) ;
>       od ;
>    od ;
>    return Copy_M ;
> end ;
function ( M ) ... end
gap>
gap> q := 5 ;
5
gap> GL2Fq := GeneralLinearGroup(2, q) ;
GL(2,5)
gap> for g in GL2Fq.generators do Print(pretty(g), "\n") ; od ;
[ [ 2, 0 ], [ 0, 1 ] ]
[ [ 4, 1 ], [ 4, 0 ] ]
gap> Size(GL2Fq) ;
480
gap> # h := generateur de Fq-{0}
gap> h := Z(q) * [[1, 0], [0, 1]] ;; pretty(h) ;
[ [ 2, 0 ], [ 0, 2 ] ]
gap> Order(GL2Fq, h) ;
4
gap>
gap> # C := centre de GL(2,Fq)
gap> C := Subgroup(GL2Fq, [h]) ; C.name := "C" ;
Subgroup( GL(2,5), [ [ [ Z(5), 0*Z(5) ], [ 0*Z(5), Z(5) ] ] ] )
"C"
gap> Size(C) ;
4
gap> C = Centre(GL2Fq) ;
true
gap>
gap> # PGL2(Fq) = GL2(Fq)/centre
gap> PGL2Fq := GL2Fq / C ;  PGL2Fq.name := "PGL2Fq" ;
(GL(2,5) / C)
"PGL2Fq"
gap> Size(PGL2Fq) ;
120
gap>
gap> # l'application canonique class : GL2Fq -> PGL2Fq
gap> class := function(x) return FactorGroupElement(C, x) ; end ;
function ( x ) ... end
gap>
gap> # sous-groupe K de Jean-Louis d'ordre 24
gap> f := class((Z(q)^0 * [[1, 1], [2, 3]])) ;
FactorGroupElement( C, [ [ Z(5)^3, Z(5)^3 ], [ Z(5)^0, Z(5)^2 ] ] )
gap> of := Order(PGL2Fq, f) ;
3
gap> g := class((Z(q)^0 * [[1, 3], [3, 1]])) ;
FactorGroupElement( C, [ [ Z(5)^2, Z(5) ], [ Z(5), Z(5)^2 ] ] )
gap> og := Order(PGL2Fq, g) ;
4
gap> K := Subgroup(PGL2Fq, [f, g]) ; K.name := "K" ;
Subgroup( (GL(2,5) / C),
[ FactorGroupElement( C, [ [ Z(5)^3, Z(5)^3 ], [ Z(5)^0, Z(5)^2 ] ] ),
  FactorGroupElement( C, [ [ Z(5)^2, Z(5) ], [ Z(5), Z(5)^2 ] ] ) ] )
"K"
gap> Size(K) ;
24
gap>
gap> K_Left_Cosets := LeftCosets(PGL2Fq, K) ;
[ (FactorGroupElement( C, [ [ Z(5)^0, 0*Z(5) ], [ 0*Z(5), Z(5)^0 ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5)^2 ], [ Z(5)^0, Z(5)^2 ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5) ], [ Z(5)^0, Z(5)^2 ] ] )*K),
  (FactorGroupElement( C, [ [ Z(5)^2, Z(5)^0 ], [ Z(5)^2, 0*Z(5) ] ] )*K),
  (FactorGroupElement( C, [ [ 0*Z(5), Z(5)^0 ], [ Z(5)^0, Z(5)^2 ] ] )*K) ]
gap> Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(PGL2Fq, K_Left_Cosets, OnLeft) ;
Group( (2,4,5,3), (1,4,2) )
gap> perm := OperationHomomorphism(PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;
OperationHomomorphism( (GL(2,5) / C), Group( (2,4,5,3), (1,4,2) ) )
gap>
gap> IsSurjective(perm) ;
true
gap> PreImagesRepresentative(perm, (1,4,2)) ;
FactorGroupElement( C, [ [ Z(5)^2, Z(5)^0 ], [ Z(5)^2, 0*Z(5) ] ] )
gap> PreImagesRepresentative(perm, (1,4)) ;
false
gap>
gap> LogTo() ;

--------------------------------------------------------------------------

Best regards

--
Claude Quitte
Dept de Mathematiques
40 Av du recteur Pineau
86022 Poitiers Cedex FRANCE
E-mail Internet : quitte@knuth.univ-poitiers.fr
Fax : 33-49-45-40-10



From martin.schoenert@math.rwth-aachen.de Mon Nov 20 22:38:00 1995
Date:           Mon, 20 Nov 95 22:38:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: PreImagesRepresentative

Claude Quitte wrote in his e-mail message of 1995/11/18

    Here a problem with the function "PreImagesRepresentatives" wich
    returns "false" instead of an antecedent (which exists !).

    ...definition of PGL2Fq and K ommited...

    K_Left_Cosets := LeftCosets(PGL2Fq, K) ;
    Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(
        PGL2Fq, K_Left_Cosets, OnLeft) ;
    perm := OperationHomomorphism(
        PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;

The problem is that 'PGL2Fq' does *not* operate on the left cosets via
'OnLeft' (because 'OnLeft(OnLeft(<cos>,<g1>),<g2>) = <g2>*<g1>*<cos>',
which is different from '<g1>*<g2>*<cos> = OnLeft(<cos>,<g1>*<g2>)').
Note that 'Operation' does not check whether one really has an operation,
because this is too expensive in general.

We will probably rename 'OnLeft' to something like 'OnLeftAntiOperation'
and add the following function 'OnLeftInverse' in a future release.

    OnLeftInverse := function ( pnt, g )
        return g^-1 * pnt;
    end;

If you really want to find an element of 'PGL2Fq' that permutes the left
cosets of 'K' in a prescribed way by multiplication from the left (in
this example exchanging the first and fourth coset), you should use

    Operation_Of_PGL2Fq_On_K_Left_Cosets := Operation(
        PGL2Fq, K_Left_Cosets, OnLeftInverse) ;
    perm := OperationHomomorphism(
        PGL2Fq, Operation_Of_PGL2Fq_On_K_Left_Cosets) ;

and then you must take the inverse of the preimage of course

    gap> PreImagesRepresentative(perm, (1,4,2)) ^-1 ;
    FactorGroupElement( C, [ [ Z(5)^2, Z(5)^0 ], [ Z(5)^2, 0*Z(5) ] ] )
    gap> PreImagesRepresentative(perm, (1,4)) ^-1 ;
    FactorGroupElement( C, [ [ Z(5)^0, Z(5)^0 ], [ Z(5), Z(5)^2 ] ] )

Alternatively you could use right cosets instead of left cosets and
'OnRight' instead of 'OnLeft'. (GAP calculates left cosets by computing
right cosets and inverting representatives anyway).

As a final hint, if you plan to do a lot of computations with a matrix
group or even a factor group of a matrix group like PGL_2(F_q), it is
advisable to replace this group by an isomorphic permutation group
together with an isomorphism back to the matrix group. For example, take
the action of GL_2(5) on lines (i.e., projective points).

    gap> G := GL( 2, 5 );
    GL(2,5)
    gap> v := [1,0] * GF(5).one;
    [ Z(5)^0, 0*Z(5) ]
    gap> orb := Orbit( G, v, OnLines );;
    gap> P := Operation( G, orb, OnLines );
    Group( (2,3,5,6), (1,2,4)(3,6,5) )
    gap> hom := OperationHomomorphism( G, P );
    OperationHomomorphism( GL(2,5), Group( (2,3,5,6), (1,2,4)(3,6,5) ) )
    gap> Kernel( hom );
    Subgroup( GL(2,5), [ [ [ Z(5), 0*Z(5) ], [ 0*Z(5), Z(5) ] ] ] )

Now you can use the homomorphism functions to convert between matrices in
GL_2(5) and permutations in the permutation group isomorphic to PGL_2(5).

Hope this helps,

Martin.

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



From frank.celler@math.rwth-aachen.de Tue Nov 21 14:28:00 1995
Date:           Tue, 21 Nov 95 14:28:00 +0100 (MET)
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        /pub/incoming

Dear Gap Forum,

the following exercises,  programs, functions and utilities were  sent
to us and made available  on our ftp server  "ftp.math.rwth-aachen.de"
(137.226.152.6).  We emphasise once more  that they are made available
as sent without *any* warranty from  us.  Please mail any questions to
the respective originators whose email addresses are given below.

Further such submissions are welcome, best wishes

  Frank Celler and Joachim Neubueser

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/tmp
====

  exercises.zoo
  -------------
    - unsorted Galway exercises, email <Gap-Trouble@Math.RWTH-Aachen.DE>
    - exercises from Peter Webb <webb@math.umn.edu>

/pub/incoming
=============

  AbStab.g, AbStab.doc
  --------------------
    - for representing elements of a permutation group in terms of its
      generators
    - written by Philip Osterlund <osterlu@s6.math.umn.edu>

  DCE-1.0.zoo
  -----------
    - Double Coset Enumerator
    - written by Steve Linton <sal@dcs.st-and.ac.uk>

  GAP-Manual-html.doc, GAP-Manual-html.tgz
  ----------------------------------------
    - The file 'GAP-Manual-html.tgz' is a 'gzip'-ed 'tar' archive containing
      the GAP manual as an HTML document.  Unpacked it requires about 4 MBytes
      of disk space.  You can read this using your favorite WWW browser.
    - written by Martin Schoenert <Martin.Schoenert@Math.RWTH-Aachen.DE>

  MeatAxe-2.2.2.tgz
  -----------------
    - MeatAxe Version 2.2.2
    - contact <sam@math.rwth-aachen.de>

  WeylMod.g, WeylMod.doc
  ----------------------
    - WeylMod.g is a small collection of routines that work with
      representations of simple complex Lie algebras. It provides the
      following:
    - (1) definitions of Killing form for all finite simple Lie algebras,
      and all affine Lie algebras (Kak-Moody algebras) -- both direct and
      twisted.
    - (2) Weyl's equation for the dimension of a representation given its
      highest weight.
    - (3) Freudenthal's recursive algorithm to generate all weights and
      multiplicities of a representation given its highest weight.
    - written by Jacob Hirbawi <JcbHrb@CERF.net>

  bin3r4p2-mac-syc-101.sea.bin, src3r4p2-mac-syc-101.sea.bin
  ----------------------------------------------------------
    - port of GAP for Macintosh
    - written by Burkhard Hoefling <HOEFLING@Mat.Mathematik.Uni-Mainz.DE>

  coco.grp, coco.tex
  ------------------
    - When you read the file `coco.grp' into GAP, a function will be
      defined that allows you to construct the primitive permutation
      representations of the simple groups of order less than~$10^6$,
      except for the two-dimensional linear groups. The groups come
      together with the computer package COCO for calculations with
      COherent COnfigurations.  COCO was written by A.~A.~Ivanov,
      I.~Farad\v{z}ev and M.~Klin and ported to UNIX machines by
      A.~Brouwer.
    - The information about primitive groups was translated into
      GAP-format by Heiko Thei{\ss}en <Heiko.Theissen@math.rwth-aachen.de>.

  ctpg.g, ctpgexam.g
  ------------------
    - This file contains a couple of GAP (version 3.3) functions that
      help in the following situation:
      Input: G a finitely presented group, H a homomorphic image of G and U
        a subgroup of H.
      Output: The abelian invariants of the complete preimage of U in G.
    - written by Werner Nickel <Werner.Nickel@math.rwth-aachen.de>

  emacs-gap-mode-1.96.tar.gz, emacs-gap-mode.readme
  -------------------------------------------------
    - GAP mode for emacs
    - written by Michael Smith

  fisk.zoo
  --------
    - GAP manual to EMACS info format translator
    - written by Steve Fisk <fisk@bowdoin.edu>

  gap.m, math.g, gapmath.doc
  --------------------------
    - GAP to Mathematica, Mathematica to GAP translator
    - written by Sebastian Egner <egner@zkm.de>

  minnesota.exa
  -------------
    - this is an analysis, using GAP, of a deficiency zero presentation ...
    - by Mike F. Newman <Mike.Newman@maths.anu.edu.au>

  nrsg.diss.ps.gz, nrsg.tar.gz
  ----------------------------
    - One of our students has recently completed his Magister Thesis
      on the implementation of Nearring functions in GAP, and as
      a byproduct has created GAP functions to do endomorphisms,
      automorphisms etc of groups.
    - contact Tim Boykett <tim@bruckner.stoch.uni-linz.ac.at>

  semigroup.g, semigroup.doc
  --------------------------
    - functions for semi groups
    - written by Marcel Widi,
      email Tim Boykett <tim@bruckner.stoch.uni-linz.ac.at>

  split.zoo, split-merge.doc
  --------------------------
    - splits and merges large files into smaller pieces,
      useful when transferring files on floppy disk
    - uploaded by Steve Linton <sal@cs.st-and.ac.uk>

  stamp.g, stamp.doc
  ------------------
    - stamp.g - Routines for computing in very large permutation groups
    - written by Steve Linton <sal@cs.st-and.ac.uk>

  pq.v1-3.tar.gz
  --------------
    - ANU pq version 1.3
    - written by Eamonn O'Brien <Eamonn.OBrien@Math.RWTH-Aachen.DE>

  xgap1r3.zoo, xgap1r3-dvi.zoo, xgap1r3-*-*-*.zoo
  -----------------------------------------------
    - XGAP - a graphical frontend for GAP under X-Windows, Version 1.3,
      xgap1r3-dvi.zoo contains the DVI file of the manual, xgap1r3-*-*-*.zoo
      contains binaries for the corresponding machine and operating
      system.
    - written by Frank Celler <Frank.Celler@Math.RWTH-Aachen.DE>



From michael.smith@maths.anu.edu.au Wed Nov 22 22:33:23 1995
Date:           Wed, 22 Nov 95 22:33:23 +1000
From:           "Michael Smith" <michael.smith@maths.anu.edu.au>
Subject:        new GAP module package

I'm in the process of posting a file called moddist.tar.z (gzipped) to the
anonymous ftp site at Aachen
(<ftp://ftp.math.rwth-aachen.de/pub/incoming>). The connection from
Australia to Germany is atrocious, but hopefully the file will get there
within the next day or two.

This package contains various functions for computing information about
modules for matrix algebras. I've included the README file below which
lists most of the important functions, and there are a number of (hopefully
informative) example files included with the code to get people started.

Hope this is of use to someone out there. Comments and suggestions welcome.

Currently there is no user documentation (apart from the README file), but
examining the README file and the example files would be a good first step
for anyone interested in using the package.

Cheers,
Michael.


---------------------------------------------------------------------------
README for GAP modules code

Michael J Smith, School of Mathematical Sciences, ANU
21:07 Wed 22 Nov 1995
---------------------------------------------------------------------------

The files in subdirectory "modules" contain routines for computing with
modules over matrix group algebras.  Included are routines for:

(1) defining module records:
        gap> M := GModule([mat1, mat2, ...]);

(2) computing the decomposition of a module into a direct sum of
indecomposable summands:
        gap> computeDecomposition(M);

(3) computing isomorphisms between modules:
        gap> X := isomorphismModules(M1, M2);

(4) computing module endomorphism algebra:
        gap> E := moduleEndAlgBasis(M);

(5) computing module homomorphism groups:
        gap> H := moduleHomBasis(M1, M2);

(6) computing module automorphisms; generators for the multiplicative
subgroup of invertible elements of the endomorphism algebra, and the order
of this matrix group:
        gap> A := moduleAutGenerators(M);
        gap> o := moduleAutOrder(M);

(7) computing the centraliser in GL(n,p) of a subgroup of GL(n,p):
        gap> U := MatGroup([mat1, mat2, ...], GF(p));
        gap> C := MatGroupCentraliser(U);
(note that this is equivalent to the computation in (6))

(8) assorted other routines used by the above.


There are a number of example files that demonstrate most of the routines
that are available.


---------------------------------------------------------------------------
INSTALLATION:

The simplest way to use these files is to define a gap variable called
"LOCALNAMEmodules" pointing to the subdirectory "modules", and then to
issue the command

        gap> Read(Concatenation(LOCALNAMEmodules, "init.gap"));

For example, with the "modules" directory copied to /home/user/gap/modules/,
issue the following commands to GAP:

        gap> LOCALNAMEmodules := "/home/user/gap/modules/";
        gap> Read(Concatenation(LOCALNAMEmodules, "init.gap"));


---------------------------------/|-|--|-|--|-Michael-Smith------------------
 Michael.Smith@maths.anu.edu.au /-| |\ | |  | Mathematics (CMA)
-------------------------------/--|-|-\|-|_/|-Australian-National-University-

http://wwwmaths.anu.edu.au/~smith/Michael_Smith.html



From s8910859@student.ecel.uwa.edu.au Fri Nov 24 16:03:24 1995
Date:           Fri, 24 Nov 95 16:03:24 +0800
From:           "David Wood" <s8910859@student.ecel.uwa.edu.au>
Subject:        Problem with ranges in GAP

GAP seems to have some problems whenever doing an assignment or
arithmetic operation to an element of a list which is represented as a
range with a negative difference.

For example:

gap> a := [10,8..2];
[ 10, 8 .. 2 ]
gap> a[3] := a[3] + 4;
10
gap> a;
[ 10, -2, 10,, ]

Is there any way to force GAP to represent a list using the ordinary
list representation, instead of the compact range representation, even
when GAP has realised the list is in fact a range?

-----------------------------------------------------------------------
David Wood                                15 Vivian Way, Boya, WA 6056,
s8910859@rand.ecel.uwa.edu.au             Australia.  (+61 9) 299 6471
-----------------------------------------------------------------------



From martin.schoenert@math.rwth-aachen.de Fri Nov 24 23:59:00 1995
Date:           Fri, 24 Nov 95 23:59:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Problem with ranges in GAP

David Wood wrote in his e-mail message of 1995/11/24

    GAP seems to have some problems whenever doing an assignment or
    arithmetic operation to an element of a list which is represented as a
    range with a negative difference.

    gap> a := [10,8..2];
    [ 10, 8 .. 2 ]
    gap> a[3] := a[3] + 4;
    10
    gap> a;
    [ 10, -2, 10,, ]

I'm unable to repeat this problem here.  Could you tell us which version
of GAP you are using, and on which machine this happens?  Maybe other
GAP users can try this too and write us if this fails for them too
(maybe this is a machine/system/compiler dependent problem).
I suggest that we move this to 'GAP-Trouble@Math.RWTH-Aachen.DE' until
we have sorted it out.

He continued

    Is there any way to force GAP to represent a list using the ordinary
    list representation, instead of the compact range representation, even
    when GAP has realised the list is in fact a range?

Simply adding '0' to the range will do the trick.  'IsRange' can be used
for the other direction (i.e., if you have a list that you know is a
range).

Martin.

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



From neis@cs.uni-sb.de Mon Nov 27 19:55:07 1995
Date:           Mon, 27 Nov 95 19:55:07 +0100
From:           "Stefan Neis" <neis@cs.uni-sb.de>
Subject:        Input to GAP ?

        Hi there,

(In fact, the following problem occured while using "KASH", but since
they use the "GAP-engine", I tought, this would be the right adress to
ask...):

I'm having some trouble finding out, how to read input from a file
into GAP. Say I produced a matrix and wrote it to a file using
"PrintTo". Is there any way to get it back into memory the next day?
"Read" doesn't seem to work, if I don't read files, which look like
the following line:
A:=Mat(Z,[[1,2],[3,4]]);
(i.e. I have to supply a command, not just an object, in the file.)

But with this method, I always  have to remember, which variable I was
using, when creating the file...

        Yours
                Stefan Neis



From alexander.hulpke@math.rwth-aachen.de Tue Nov 28 16:59:55 1995
Date:           Tue, 28 Nov 95 16:59:55 +0100
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: Input to GAP

Dear GAP-Forum,

Stefan Neis asked:

> I'm having some trouble finding out, how to read input from a file
> into GAP. Say I produced a matrix and wrote it to a file using
> "PrintTo". Is there any way to get it back into memory the next day?
> "Read" doesn't seem to work, if I don't read files, which look like
> the following line:
> A:=Mat(Z,[[1,2],[3,4]]);
> (i.e. I have to supply a command, not just an object, in the file.)

When printing the object, print it with
PrintTo("file","A:=",A,";\n");

There is no way within GAP to deduce a variables name from the variable, so
you'll have to supply the name yourself. Alternatively you can edit the file
to add the assignement and the semicolon (I'm sure you have found this
out already). A more comfortable way would be to use the following function:

    SaveTo:=function(file,object,name)
      PrintTo(file,name,":=",object,";\n",
              "Print(\"#I  ",name," loaded\\n\");\n");
    end;

The added print command prints the name of the defined variable as a
reminder when loading the file. Thus when saving an object using

   SaveTo("file",A,"A");

`Read'ing "file" produces the reminder line

   #I  A loaded

> But with this method, I always  have to remember, which variable I was
> using, when creating the file...

As a slight variation, you could use the following pair of functions
(assuming you never use the global variable 'READ_OBJECT'):

    PrintToObject := function ( file, object )
        PrintTo( file, "READ_OBJECT := \n", object, ";\n" );
    end;

    ReadObject := function ( file )
        Read( file );
        return READ_OBJECT;
    end;

then you can save objects with PrintToObject("filename",A); and load them to
a variable by the assignement A:=ReadObject("file"); without any reference
to variable names used when saving the object.

Hope this helps,

      Alexander Hulpke



From pbrown@math.berkeley.edu Thu Nov 30 01:08:04 1995
Date:           Thu, 30 Nov 95 01:08:04 -0800
From:           "Paul Robert Brown" <pbrown@math.berkeley.edu>
Subject:        GAP + automata

Has anyone out there written a routine that interfaces GAP and the
automatic groups software by D. Epstein, D. Holt, and S. Rees?

If not, I will very likely attempt to do so myself, and I would
cheerfully share any successes if the matter is or general interest.

Yours,

Paul Brown



From delgado@mathematik.uni-bielefeld.de Thu Nov 30 12:30:54 1995
Date:           Thu, 30 Nov 95 12:30:54 +0100
From:           "Olaf Delgado" <delgado@mathematik.uni-bielefeld.de>
Subject:        Re: GAP + automata

Hi Paul Brown, you wrote to the forum:

> Has anyone out there written a routine that interfaces GAP and the
> automatic groups software by D. Epstein, D. Holt, and S. Rees?
>
> If not, I will very likely attempt to do so myself, and I would
> cheerfully share any successes if the matter is or general interest.

I think it would be very useful to have such a routine. GAP handles
finitely presented groups gracefully, so it should be a natural front end
for the automatic groups software.

Regards,
O. Delgado

--
   ////         Olaf Delgado Friedrichs, Uni Bielefeld, Mathematik
   Olaf         Postfach 100313                  (room:  V4-109)
   `='          D-33501 Bielefeld, Germany       (phone: +49 521 106-4765)
                           http://www.mathematik.uni-bielefeld.de/~delgado



From hoppe@math.tu-berlin.de Thu Nov 30 12:40:39 1995
Date:           Thu, 30 Nov 95 12:40:39 +0100
From:           "Andreas Hoppe" <hoppe@math.tu-berlin.de>
Subject:        Re: Input to GAP

Dear GAP-Forum,

Stefan Neis quoted:

> (In fact, the following problem occured while using "KASH", but since
> they use the "GAP-engine", I tought, this would be the right adress to
> ask...):
You're wrong with that one because, although KASH is using the GAP
parser, interpreter, basics types, it supplies its own types which follow
a slightly different concepts due to the fact that the major part of
KANT/KASH is written low-language (in C) in contrast to GAP where most
algorithms are implemented in high-language (GAP interpreter).

Although there's no such thing as a KASH-Forum You can post problems
like that to kant@math.tu-berlin.de .

To Your problem:
There are two things to distinguish: GAP matrices (list of lists) and
KANT matrices:

kash> M:=[[1,2],[3,4]];
[ [ 1, 2 ], [ 3, 4 ] ]
kash> TYPE(M);
"list"
kash> A:=Mat(Z,M);
[1 2]
[3 4]

kash> TYPE(A);
"KANT matrix"

The printout of most of the KASH types is not rereadable and only
printed for information. But for KANT matrices over Z You can use the
function MatToRowList() which is quite the opposite to Mat(*,.).

To get what You really want Alexander's function looks like that:

    SaveKantMatZTo:=function(file,mat,name)
      PrintTo(file,name,":=Mat(Z,",
        MatToRowList(mat),");\n",
        "Print(\"#I  ",name," loaded\\n\");\n");
    end;

kash> SaveKantMatZTo("mat1.kash",A,"B");
kash> Read("mat1.kash");
#I  B loaded
kash> B;
[1 2]
[3 4]

The latest release of KASH features a new BagWrite/BagRead
concept addressing exactly this problem in a more general
approach. See Manual for details.

Cheers
Andreas Hoppe




P.S.
KASH is a tool for sophisticated computations
in number fields and is availabe free of charge from
ftp.math.tu-berlin.de
User: ftp
Directory: /pub/algebra/Kant/Kash



From quitte@knuth.univ-poitiers.fr Thu Nov 30 15:04:20 1995
Date:           Thu, 30 Nov 95 15:04:20 NFT
From:           "Claude Quitte" <quitte@knuth.univ-poitiers.fr>
Subject:        Finite Prime Fields

In a G.A.P session, is there a way to obtain a printing of ALL the elements of
Fp (Finite Prime Field of size p) like an integer on the range 0..p-1 ?  Of
course, for some variables, I can use the function IntFFE to make the
correspondance. But I want that this type of printing operates for the objects
like list, matrix of elements of a prime field and so on ...

Thanks.

--
Claude Quitte
Dept de Mathematiques
40 Av du recteur Pineau
E-mail Internet : quitte@knuth.univ-poitiers.fr



From quitte@knuth.univ-poitiers.fr Thu Nov 30 15:10:36 1995
Date:           Thu, 30 Nov 95 15:10:36 NFT
From:           "Claude Quitte" <quitte@knuth.univ-poitiers.fr>
Subject:        x -> f(x)

I have a warning using the construction x -> f(x, i) where i is the parameter
of a loop. It seems that G.A.P. builds a function with two parameters x, i and
says "i undefined global variable" (it's only a warning).

---------------
A := [12, 56, 45, 2, 76, 11, 7] ;
for i in [0..2] do
   Print(" elemts = ", i, " mod 3 : ", Filtered(A, x -> RemInt(x, 3) = i), "\n") ;
od ;
-----------------------

---------------------------
gap> A := [12, 56, 45, 2, 76, 11, 7] ;
[ 12, 56, 45, 2, 76, 11, 7 ]

gap> for i in [0..2] do
>    Print(" elemts = ", i, " mod 3 : ", Filtered(A, x -> RemInt(x, 3) = i), "\n") ;
Syntax error: warning, undefined global variable
   Print(" elemts = ", i, " mod 3 : ", Filtered(A, x -> RemInt(x, 3) = i), "\n\") ;
> od ;

 elemts = 0 mod 3 : [ 12, 45 ]
 elemts = 1 mod 3 : [ 76, 7 ]
 elemts = 2 mod 3 : [ 56, 2, 11 ]
-------------------------------

Thanks.

--
Claude Quitte
Dept de Mathematiques
40 Av du recteur Pineau
E-mail Internet : quitte@knuth.univ-poitiers.fr



From werner.nickel@math.rwth-aachen.de Thu Nov 30 15:37:00 1995
Date:           Thu, 30 Nov 95 15:37:00 +0100 (MET)
From:           "Werner Nickel" <Werner.Nickel@Math.RWTH-Aachen.DE>
Subject:        Re: GAP + automata

Dear forum readers,

Paul Brown asks:

> Has anyone out there written a routine that interfaces GAP and the
> automatic groups software by D. Epstein, D. Holt, and S. Rees?
>
>If not, I will very likely attempt to do so myself, and I would
>cheerfully share any successes if the matter is or general interest.

Here is a short answer to the question.  Since Derek Holt is a reader
of this forum he might want to give a more detailed answer.

Derek has a new version of the automatic group software called KBMAG.
It includes a GAP interface.  It can be obtained via Derek's web home
page http://www.maths.warwick.ac.uk/~dfh/ or from the Warwick
mathematics ftp server ftp.maths.warwick.ac.uk:/people/dfh/ via
anonymous ftp.

With kind regards, Werner Nickel.



From prohlep@konig.elte.hu Thu Nov 30 14:05:10 1995
Date:           Thu, 30 Nov 95 14:05:10 +0000 (GMT)
From:           "Peter Prohle" <prohlep@konig.elte.hu>
Subject:        Re: GAP + automata

> Has anyone out there written a routine that interfaces GAP and the
> automatic groups software by D. Epstein, D. Holt, and S. Rees?


> I think it would be very useful to have such a routine. GAP handles
> finitely presented groups gracefully, so it should be a natural front end
> for the automatic groups software.


I have something similar.
Prof. Joachim Neubueser suggested me to interface the stand alone
Knuth-Bendix written by the authors named above.
I have an almost completed and not satisfactorily tested
K-B written in GAP. As soon as I finish the current two papers,
I will complete and release the Knuth-Bendix for GAP.

However, the KBMAG (stands for Knuth-Bendix on Monoids and Automatic Groups),
is naturally much more powerful, and has a suitable interface to GAP.
A further important feature, that the input and output format for files
was developed by the GASP group, and conforms to the syntax of the GAP system.

In spite of the facts above, it makes sense to have a GAP implementation
of the Knuth-Bendix (for monoids and groups) as well.
(1)     Some times the speed is not as important, as it is comfortable to
remain entirely within the GAP system. You might want to play with different
settings, and you might prefer the benefit of the flexible access to and
control of the algorithm, because it is written in GAP.
(2)     It is on my todo list (or at least on my wish list), to profile
the GAP implementation and to write the appropriate kernel support.

        Peter Prohle



From dfh@maths.warwick.ac.uk Fri Dec  1 10:35:33 1995
Date:           Fri, 01 Dec 95 10:35:33 +0000 (GMT)
From:           "Derek Holt" <dfh@maths.warwick.ac.uk>
Subject:        Re: GAP + automata

Dear forum readers,

Paul Brown asks:

> Has anyone out there written a routine that interfaces GAP and the
> automatic groups software by D. Epstein, D. Holt, and S. Rees?
>
>If not, I will very likely attempt to do so myself, and I would
>cheerfully share any successes if the matter is or general interest.

to which Werner Nickel replies:

> Here is a short answer to the question.  Since Derek Holt is a reader
> of this forum he might want to give a more detailed answer.
>
> Derek has a new version of the automatic group software called KBMAG.
> It includes a GAP interface.  It can be obtained via Derek's web home
> page http://www.maths.warwick.ac.uk/~dfh/ or from the Warwick
> mathematics ftp server ftp.maths.warwick.ac.uk:/people/dfh/ via
> anonymous ftp.

This is just to confirm what Werner says.
The current interfact of KBMAG with GAP is a little rudimentary, but it
can be made to work.

After making the package KBMAG, you go into a directory containing some
GAP library files, start up GAP and read in these files.
You then define a finitely presented group G, say, in GAP, and from it you
calculate an object known as a rewriting-system, which the KBMAG programs
use as input. You can then call the automata program as an external program
from within GAP. If successful, you can reduce words in G to their
normal form, and enumerate the set of words in normal form (usually
up to a given word-length). You can also examine the finite state automata
associated with the automatic structure of G from within GAP if you want to.

There are plans to make KBMAG into an official GAP share package, but some
details of the interface remain to be sorted out, so this may take a few
more months yet.

In the mean time, it would be very helpful if you could try out this
interface and let me know of any problems you have setting it up, anything
that doesn't appear to behave the way you think it should, and any
additional facilities that you feel could be usefully provided.

Regards,
Derek Holt.



From rgilman@sitult.stevens-tech.edu Fri Dec  1 11:03:45 1995
Date:           Fri, 01 Dec 95 11:03:45 +0100
From:           "Robert Gilman" <rgilman@sitult.stevens-tech.edu>
Subject:        Re:  GAP + automata

Making a connection between GAP and the Warwick automatic groups software
is one of the goals of the GASP project, whose temporary home page is at
http://www.geom.umn.edu/~rgilman/gasp



From alexander.hulpke@math.rwth-aachen.de Fri Dec  1 12:02:18 1995
Date:           Fri, 01 Dec 95 12:02:18 +0100
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: finite Prime Fields

Dear GAP-Forum,

Claude Quitte asked:

> In a G.A.P session, is there a way to obtain a printing of ALL the elements of
> Fp (Finite Prime Field of size p) like an integer on the range 0..p-1 ?

In short: Without nasty kernel hacking there is no way. This may change
in future versions but until then you have to live with the Z(p)^e notation.

Alexander Hulpke



From aeb@win.tue.nl Fri Dec  1 16:11:11 1995
Date:           Fri, 01 Dec 95 16:11:11 +0000 (GMT)
From:           "Andries E. Brouwer" <aeb@win.tue.nl>
Subject:        Re: finite Prime Fields

Alexander Hulpke writes:

: Claude Quitte asked:

: > In a G.A.P session, is there a way to obtain a printing of ALL the elements of
: > Fp (Finite Prime Field of size p) like an integer on the range 0..p-1 ?

: In short: Without nasty kernel hacking there is no way. This may change
: in future versions but until then you have to live with the Z(p)^e notation.

This was one of the patches I posted back in gap3.2 times.
It really was a very simple change.
(Maybe some archive still has it?)

Andries



From martin.schoenert@math.rwth-aachen.de Fri Dec  1 22:39:00 1995
Date:           Fri, 01 Dec 95 22:39:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: x -> f(x)

Claude Quitte wrote in his e-mail message of 1995/11/30

    I have a warning using the construction x -> f(x, i) where i is the
    parameter of a loop. It seems that G.A.P. builds a function with two
    parameters x, i and says "i undefined global variable" (it's only a
    warning).

        A := [12, 56, 45, 2, 76, 11, 7] ;
        for i in [0..2] do
            Print(" elemts = ", i, " mod 3 : ",
                  Filtered(A, x -> RemInt(x, 3) = i), "\n") ;
        od ;

GAP emits a warning if the body of a function (in this example the body
is 'RemInt(x,3) = i') contains reference to a global variable (in this
example 'i'), which at the time the function is *read* does not have an
assigned value.  And since the entire loop is read before iterating
starts, you get the warning.  To suppress the warning, simply assign a
value to 'i'.

    A := [12, 56, 45, 2, 76, 11, 7] ;
    i := "shut up";
    for i in [0..2] do
        Print(" elemts = ", i, " mod 3 : ",
              Filtered(A, x -> RemInt(x, 3) = i), "\n") ;
    od ;

Kindly,

Martin.

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



From caranti@volterra.science.unitn.it Fri Dec  1 15:50:40 1995
Date:           Fri, 01 Dec 95 15:50:40 +0100
From:           "Andreas Caranti" <caranti@volterra.science.unitn.it>
Subject:        Re: Finite Prime Fields

Claude Quitte inquired:

>In a G.A.P session, is there a way to obtain a printing of ALL the elements of
>Fp (Finite Prime Field of size p) like an integer on the range 0..p-1 ?  Of
>course, for some variables, I can use the function IntFFE to make the
>correspondance. But I want that this type of printing operates for the objects
>like list, matrix of elements of a prime field and so on ...

I'm not sure whether this is what you ask for, but I suggest you have a
look at the "PrintMat" function in the smash package by Derek Holt, Charles
Leedham-Green, Eamonn O'Brien and Sarah Rees. It's in the file
                           pkg/smash/code/misc.g
in your GAP directory. Seems to me it does what you want at least for
matrices and lists of such. You can probably extend it to the generality
you need. Best,

Andreas Caranti



From heiko.theissen@math.rwth-aachen.de Tue Dec  5 11:04:00 1995
Date:           Tue, 05 Dec 95 11:04:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: Bug with perm group homomorphisms

Dear GAP-Forum,

half a  year ago, Mitchell Trott reported  an error in the permutation
group homomorphism  package.   This  error occurs  when   the  inverse
homomorphism of a  homomorphism to the  trivial  group is constructed.
Mitchell Trott constructed

    G := Group( (1,2) );
    hom := GroupHomomorphismByImages( G,G,G.generators,[G.identity] );

after which 'hom.generators' is '[ (1,2) ]'  and 'hom.genimages' is '[
() ]'. Now Mitchell Trott calculated

    PreImagesRepresentative( hom, () );

which GAP translates into

    ImagesRepresentative( InverseMapping( hom ), () );

Here,

    inv := InverseMapping( hom );

is constructed by interchanging source and range as well as generators
and genimages, i.e., 'inv.generators' is '[  () ]' and 'inv.genimages'
is '[ (1,2) ]'. To find  an 'ImagesRepresentative' under a permutation
group homomorphism like 'inv', GAP calculates a stabiliser chain based
on 'inv.generators'. Since these  generate the trivial group, an empty
stabiliser chain is constructed. But when 'ImagesRepresentative' steps
down the stabiliser chain of 'inv', it uses the test

    while stb.generators <> [  ]  do ...

to determine the end of the chain, and since 'inv.generators' is '[ ()
]', not '[ ]', the while-loop is executed although no stabiliser chain
is present. This leads to the error.

We must apologise for not having fixed  this earlier, and perhaps once
more because even now  we cannot offer you  a simple fix that could be
described in  the   forum. Our  correction of  this  error involved  a
modification  of  the  record  which  describes   a  permutation group
homomorphism and  this led to  changes in  several places  of the file
'permhomo.g'. The next patch of GAP-3.4 (patchlevel  3), which will be
released in the forseeable future, will contain the correction.

Sorry for any inconvenience, Heiko Thei{\ss}en



From a.mathas@ic.ac.uk Wed Dec  6 16:56:05 1995
Date:           Wed, 06 Dec 95 16:56:05 +0000
From:           "Andrew Mathas" <a.mathas@ic.ac.uk>
Subject:        package for calculating decomposition numbers of Hecke algebras

Dear GAP forum,
     this is a 'short' note to announce a new GAP package for calculating
decomposition numbers of the Iwahori-Hecke algebras of symmetric groups.
I have just uploaded the package to samson.math.rwth-aachen.de where
it appears in the /pub/incoming directory under
  specht.uu.gz
This file is a shar file; to extract the package proceed as follows:
  1. gunzip specht.uu.gz
  2. sh specht.uu
This will install SPECHT in your current directory (there are a large
number of library files, containing decomposition matrices, coming to
slightly over 1Mb). (non-UNIX users will have to gunzip the file, uudecode
it and use tar by hand, and then edit specht.g to set SPECHTHOME
accordingly).
     The package can be used for
          1. Calculating decomposition matrices of Hecke algebras of
             the symmetric groups (mainly useful in characteristic 0;
             but applicable more generally).
          2. Calculating decomposition matrices of symmetric groups. The
             decomposition matrices of S_n for the primes 2, 3, and 5
             and n < 16 are included (and for "small" (n,p) are readily
             calculated using the package).
          3. Calculating decomposition matrices of q-Schur algebras,
             although this is not fully supported as yet (no routines for
             dealing with singular partitions yet exist)
Effectively, the package allows computations to be made in the Grothendiek
ring of these algebras. In addition, many of the combinatorial tools from
the representation theory of symmetric groups are implements in the
package; for example, routines for calculating quotients
and cores of partitions, the (inverse) Littlewood-Richard rule, listing
(semi-)standard tableaux (not documented at present; the commands are
SemistandardStableaux(nu,mu) and StandardTableaux(mu) ), inducing and
restricting specht modules, PIMs, and simple modules, "inducing"
decomposition matrices, the q-Schaper theorem, Mullineux's map, dimension
formulae for these modules,... are to be found in the package.

Documentation for the package is to be found in the file specht.ps; this can
be made available through GAP's online help by letting the GAP manual.tex
know about the included file specht.tex (you will need to add a
\Include{specht} to manual.tex and re-LaTeX the manual).

At this stage the package should be considered a beta release. Currently
I am rewriting part of the package so that it makes use of a recent
conjecture (now proved by Grojnowski) for calculating decomposition matrices
of Hecke algebras over fields of characteristic 0; the basic algorithm is
written, but I have yet to fully integrate this into the package; I hope to
do this by the end of January 1996.

I would very much like to hear any comments and criticisms on the package,
and suggestions for improvements or extensions. Ultimately I would like to
add full support for calculations for Hecke algebras over finite fields,
q-Schur algebras, and general linear groups (this will not happen for quite
some time however...). Any comments on the interface or regarding any
obviously 'missing' functions are particularly welcome.

As mentioned above, I hope to have the package finished, complete with the
LLT conjecture early next year. Until then, I would much appreciate
comments and criticisms.

Regards,
     Andrew Mathas
     Imperial College
     a.mathas@ic.ac.uk



--
We are all of us in the gutter, but some of us are looking
at the stars.
                                               Oscar Wilde



From a.mathas@ic.ac.uk Thu Dec 14 23:33:45 1995
Date:           Thu, 14 Dec 95 23:33:45 +0000
From:           "Andrew Mathas" <a.mathas@ic.ac.uk>
Subject:        the SPECHT package

Dear GAP Forum,
        it has been drawn to my attention that  the SPECHT package which I deposityed in the incoming directory at Aachen contains some 'bugs'. I am currently in Australia so I won't be able to post a new version until I get back to London in January. However, these problems can either be ignored (they are harmless), or fixed by deleting the functions SemistandardTableaux and StandardTableux (the last two fuinctions in specht.g).  I added these two functions to specht.g, from another 'package' without checking themm when I was back in London for a day because somne one expressed an interest in them.

Sorry for any inconvenience,

Regards,
        Andrew Mathas



From egner@ira.uka.de Mon Dec 18 13:39:08 1995
Date:           Mon, 18 Dec 95 13:39:08 +0100
From:           "Sebastian Egner" <egner@ira.uka.de>
Subject:        Base of abelian permutation group

Dear GAP-Forum.

We are interested in the following problem:

Decompose a finite *abelian permutation group* into
a direct product of cyclic p-groups.

It is well-known that the orders of the factors are
uniquely determined. They can be computed fast by
AbelianInvariants(G). In addition if G is given as
the quotient of a free Z-module with a relator module
the Smith-normal form computation will solve the
problem. Thus the question for us is:

Is there a way of avoiding the computation of an
Fp-representation for the permutation group in order
to compute the generators of cyclic p-groups?

Alternatively: Is there a fast way to compute a
word presentation for an abelian *permutation* group?

Bye, byte,

  Sebastian Egner,
  Markus Pueschel.



From sal@dcs.st-andrews.ac.uk Tue Dec 19 14:29:24 1995
Date:           Tue, 19 Dec 95 14:29:24 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        GAP Bibliography

Dear forum,

First of all, thank you to everyone who has contributed so far. I have
identified over 150 citations or uses of GAP. The results of the search so far
may be found at URL:

http://www-theory.dcs.st-and.ac.uk/~sal/GAP/biblio

I would be grateful for further additions, corrections or comments.

        Steve Linton



From ferrero@prmat.math.unipr.it Wed Dec 20 12:03:09 1995
Date:           Wed, 20 Dec 95 12:03:09 +0100
From:           "Giovanni Ferrero" <ferrero@prmat.math.unipr.it>
Subject:        Re: GAP Bibliography

I used GAP to solve linear systems with huge rational coefficient:
a improper but tame use!
I had to touch source to print results.
Ferrero



From bettina.eick@math.rwth-aachen.de Wed Dec 20 14:24:55 1995
Date:           Wed, 20 Dec 95 14:24:55 +0100
From:           "Bettina Eick" <Bettina.Eick@Math.RWTH-Aachen.DE>
Subject:        formations in GAP

Dear GAP-forum!

This is the anouncement of the GAP formation package. The package may be
used to compute formation-theoretic subgroups of finite soluble groups
in GAP, i.e. F-residual subgroups, F-normalizers and F-covering subgroups.
Furthermore it contains the definition of a formation in GAP as well
as some functions to handle formations.

It is a package of functions written in GAP language which should be
used together with GAP 3.4.2. Furthermore 9 pages of documentation
are enclosed in the package.

It may be obtained by anonymous ftp to math.rwth-aachen.de where
the file pub/incoming/formation.tar.gz contains the package.
Use the binary mode to get the file.

Then use 'gunzip' and 'tar' to unpack the package. This will create
a new directory formation which contains a file README, the GAP library
files and the documentation. The README file contains information
how to install the package and how to print the documentation.

Have fun with it,

Bettina Eick



From mas023@bangor.ac.uk Thu Dec 21 12:57:34 1995
Date:           Thu, 21 Dec 95 12:57:34 +0000
From:           "Chris Wensley" <mas023@bangor.ac.uk>
Subject:        CompositeMapping with identity source

The following log illustrates an irritation when composing mappings
where the first map is the inclusion of an identity subgroup.
This problem arises, for example, when writing a function to perform
some operation on all normal subgroups of a group G, so that the
identity subgroup needs to be treated as a special case.

gap> G := Group( (1,2,3) );;
gap> idmap := GroupHomomorphismByImages( G, G, [ (1,2,3) ], [ (1,2,3) ] );;
gap> idsubgp := Subgroup( G, [ () ] );;
gap> G.name := "G";;  idsubgp.name := "I";;
gap> incmap := GroupHomomorphismByImages( idsubgp, G, [ () ], [ () ] );
GroupHomomorphismByImages( I, G, [ () ], [ () ] )

gap> # expect composite  (idmap)o(incmap) = incmap :-
gap> comp := CompositionMapping( idmap, incmap );
Error, Record: element 'orbit' must have an assigned value at
for <var>  in [ 1 .. Length( hom2.orbit ) ] ... in
com.operations.CompositionMapping( arg[i], com ) called from
CompositionMapping( idmap, incmap ) called from
main loop
brk> quit;

gap> # can fix the problem by inserting missing fields in incmap :-
gap> incmap.orbit := [ 1 ];;
gap> incmap.transversal := [ () ];;
gap> incmap.stabilizer := rec( generators := [ ], identity := () );;
gap> comp := CompositionMapping( idmap, incmap );
GroupHomomorphismByImages( I, G, [ () ], [ () ] )

Should this be considered a bug, or are there good reasons not to
define  .orbit, .transversal & .stabilizer  in this case?
Sorry if this has been discussed previously.

Chris Wensley (mas023@bangor.ac.uk)



From heiko.theissen@math.rwth-aachen.de Fri Dec 22 13:41:00 1995
Date:           Fri, 22 Dec 95 13:41:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        An old error in new clothes

Dear GAP forum,

Chris Wensley has reported an error which occurs when one composes two
permutation group homomorphisms one of  which has trivial source.  The
reason for this bug is the same as the one explained  in the answer to
Mitchell Trott, see below:

[excerpt from message that appeared in the GAP-forum earlier this year]

... This error occurs when  the inverse homomorphism of a homomorphism
to the trivial group is constructed. Mitchell Trott constructed

    G := Group( (1,2) );
    hom := GroupHomomorphismByImages( G,G,G.generators,[G.identity] );

after which 'hom.generators' is '[ (1,2) ]'  and 'hom.genimages' is '[
() ]'. Now Mitchell Trott calculated

    PreImagesRepresentative( hom, () );

which GAP translates into

    ImagesRepresentative( InverseMapping( hom ), () );

Here,

    inv := InverseMapping( hom );

is constructed by interchanging source and range as well as generators
and genimages, i.e., 'inv.generators' is '[  () ]' and 'inv.genimages'
is '[ (1,2) ]'. To find  an 'ImagesRepresentative' under a permutation
group homomorphism like 'inv', GAP calculates a stabiliser chain based
on 'inv.generators'. Since these  generate the trivial group, an empty
stabiliser chain is constructed. But when 'ImagesRepresentative' steps
down the stabiliser chain of 'inv', it uses the test

    while stb.generators <> [  ]  do ...

to determine the end of the chain, and since 'inv.generators' is '[ ()
]', not '[ ]', the while-loop is executed although no stabiliser chain
is present. This leads to the error.

[end of excerpt]

This bug has in  the meantime been fixed and  the fix will be released
with the  next  patch. The fix  was  so complicated,  however, that we
cannot give a   simple few-lines  correction here.   The only way   of
getting  around this  current bug  seems to be   the insertion of  the
``missing fields'' that Chris Wensley has proposed.

(In  case you are interested: There  are good reasons  for not storing
trivial orbits in a stabiliser  chain. In our fix   of the problem  we
have introduced a different method of  storing trivial images, as they
appear for the inclusion map.)

Sorry for any inconvenience,

Heiko Thei{\ss}en



From martin.schoenert@math.rwth-aachen.de Fri Dec 22 15:31:00 1995
Date:           Fri, 22 Dec 95 15:31:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Base of abelian permutation group

Sebastian Egner wrote in his e-mail message of 1995/12/18

    We are interested in the following problem:

    Decompose a finite *abelian permutation group* into
    a direct product of cyclic p-groups.

    Is there a way of avoiding the computation of an
    Fp-representation for the permutation group in order
    to compute the generators of cyclic p-groups?

There is no special function in GAP 3.4 for that purpose.  As a christmas
present I include a function that does what you want (but you have to
wait until christmas before you may use it ;-).

If <G> is an abelian permutation group, then
'IndependentGeneratorsAbelianPermGroup( <G> )' will return a list of
elements of prime-power order, such that <G> is the direct product of the
cyclic groups generated by them.  (You can also apply it to a nonabelian
permutation group, but I'm not certain what it returns in this case ;-).
This function is very fast.

IndependentGeneratorsAbelianPPermGroup := function ( P, p )
    local   inds,       # independent generators, result
            pows,       # their powers
            base,       # the base of the vectorspace
            size,       # the size of the group generated by <inds>
            orbs,       # orbits
            trns,       # transversal
            gens,       # remaining generators
            gens2,      # remaining generators for next round
            exp,        # exponent of <P>
            g,          # one generator from <gens>
            h,          # its power
            b,          # basepoint
            c,          # other point in orbit
            i, j, k;    # loop variables

    # initialize the list of independent generators
    inds := [];
    pows := [];
    base := [];
    size := 1;
    orbs := [];
    trns := [];

    # gens are the generators for the remaining group
    gens := P.generators;

    # loop over the exponents
    exp := Maximum( List( P.generators, g -> LogInt( Order( P, g ), p ) ) );
    for i  in [exp,exp-1..1]  do

        # loop over the remaining generators
        gens2 := [];
        for j  in [1..Length(gens)]  do
            g := gens[j];
            h := g ^ (p^(i-1));

            # reduce <g> and <h>
            while h <> h^0
              and IsBound(trns[SmallestMovedPointPerm(h)^h])
            do
                g := g / pows[ trns[SmallestMovedPointPerm(h)^h] ];
                h := h / base[ trns[SmallestMovedPointPerm(h)^h] ];
            od;

            # if this is linear indepenent, add it to the generators
            if h <> h^0  then
                Add( inds, g );
                Add( pows, g );
                Add( base, h );
                size := size * p^i;
                b := SmallestMovedPointPerm(h);
                if not IsBound( orbs[b] )  then
                    orbs[b] := [ b ];
                    trns[b] := [ () ];
                fi;
                for c  in ShallowCopy(orbs[b])  do
                    for k  in [1..p-1]  do
                        Add( orbs[b], c ^ (h^k) );
                        trns[c^(h^k)] := Length(base);
                    od;
                od;

            # otherwise reduce and add to gens2
            else
                Add( gens2, g );

            fi;

        od;

        # prepare for the next round
        gens := gens2;
        pows := OnTuples( pows, p );

    od;

    # return the indepenent generators
    return inds;
end;

IndependentGeneratorsAbelianPermGroup := function ( G )
    local   inds,       # independent generators, result
            p,          # prime factor of group size
            gens,       # generators of <p>-Sylowsubgroup
            g,          # one generator
            o;          # its order

    # loop over all primes
    inds := [];
    for p  in Union( List( G.generators, g -> Factors(Order(G,g)) ) )  do

        # compute the generators for the <p>-Sylowsubgroup
        gens := [];
        for g  in G.generators  do
            o := Order(G,g);
            while o mod p = 0  do o := o / p; od;
            if g^o <> g^0  then Add( gens, g^o );  fi;
        od;

        # append the independent generators for the <p>-Sylowsubgroup
        Append( inds,
                IndependentGeneratorsAbelianPPermGroup(Group(gens,()),p) );

    od;

    # return the independent generators
    return inds;
end;

Regards, Martin.

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



From martin.schoenert@math.rwth-aachen.de Fri Dec 22 15:41:00 1995
Date:           Fri, 22 Dec 95 15:41:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Upgrade for GAP 3.4 patchlevel 2 (V3R4P2) to patchlevel 3 (V3R4P3)

This is to  announce the availability of  the third upgrade  for GAP 3.4.
This upgrade brings version 3 release 4 patchlevel  2 (V3R4P2) to version
3 release 4 patchlevel 3 (V3R4P3).  The priority of this upgrade is high.

This  upgrade fixes all known bugs  in the  library.   Among them are the
bugs  in 'LowIndexSubgroupsFpGroup' (if a  nontrivial subgroup is given),
in 'GroupHomomorphismByImages'  (when images  of generators are trivial),
in 'RepresentativeOperation' (when it  is applied to a  symmetric group),
in  'EquivalenceTest' (for example  when called from 'MaximalSubgroups'),
and with projections from subdirect products.

This upgrade  adds the library  of  perfect groups of  size at  most 10^6
(excluding 11 sizes) by D.Holt and W.Plesken  (brought into GAP format by
V.Felsch).    It  also adds the  library  of   irreducible maximal finite
integral matrix   groups of dimension   at  most 24  by G.Nebe,  M.Pohst,
W.Plesken, and B.Souvignier (again brought  into GAP format by V.Felsch).
It also extends the library of transitive groups up to degree 15.

This upgrade *does* change the manual.

This upgrade does not change the kernel.  Thus you need not recompile.

This upgrade adds the    Double Coset Enumerator contributed package   by
S.Linton.  It also contains  newer versions of   the ANUpq (1.3)  and the
XGAP (1.3) contributed packages.

The upgrade is  *not* available as patch  file.  Such a patch file  would
simply be too large (over 3 MBytes).

Martin.

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



From joachim.neubueser@math.rwth-aachen.de Wed Dec 27 11:48:14 1995
Date:           Wed, 27 Dec 95 11:48:14 +0100
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Interim Report

Dear Forum members,

In a letter of June  30, 1995, I had  informed you that in time before
my retirement in July 1997, 'GAP Headquaters' will move from Aachen to
St.  Andrews  in order to  secure a continued development  of GAP.  In
that letter, I had promised that I would keep you fully informed about
steps taken in that move.  Now, half a year later,  it may be time for
an interim report and I am very glad that at the same  time I can give
you first hints  to a number of  events coming  forth in Computational
Group Theory.

Cooperation between  Aachen and St.  Andrews  has been intensive since
last June. Ed  Robertson and Steve Linton  have  been visiting Aachen,
and in particular   Steve has  during   several  visits followed   and
discussed very closely  the ongoing work on  GAP 4. On the other hand,
Goetz Pfeiffer, who got  his PhD working at  Lehrstuhl D  with Herbert
Pahlings, is  now spending two years  of an HCM sponsored postdoc time
at St.  Andrews.  Also Werner Nickel, who got his diploma at Lehrstuhl
D as one of the 'gang of four' that started  GAP, and then got his PhD
with Mike Newman in Canberra, after two further  years as a postdoc at
Lehrstuhl D, is now going for a three  years' assignment as a research
and teaching fellow to St. Andrews.

In my letter   of June  30,  I had  also   rather vaguely hinted    at
strengthening the  international cooperation   in the development   of
GAP. Today I can report about some steps taken.

1. The  'GAP Council'.

A number of senior colleagues, engaged in a broad spectrum of areas in
computational group theory have agreed   to form a 'GAP Council'  that
will advise  on broad policy  issues in  the continued development  of
GAP.  An important function of  this  council will be   its role as an
editorial board for external contributions to GAP. Since this is a new
idea,  I   want to explain   it under  the separate   point   2 in the
sequel. The present members of the council are:

Mike Atkinson,  St. Andrews
Andrea Caranti, Trento
Gene Cooperman, Northeastern U., Boston
Derek Holt, Warwick U., Coventry
Steve Linton,  St. Andrews,
Mike  Newman, ANU, Canberra
Herbert Pahlings, RWTH Aachen
Cheryl Praeger, UWA, Perth
Ed  Robertson, St. Andrews
Akos Seress, OSU, Columbus, Ohio
Charles Wright, U. of Oregon.

Their full addresses and e-mail addresses will be given in an appendix.


2. Refereeing GAP contributions.

We are planning to introduce a  more formal procedure of acceptance of
external contributions  to  GAP.  This will in  some  way resemble the
procedure of  accepting a  paper for  publication  in a periodical and
will in a  similar  way serve the  double  purpose of maintaining  the
quality of contributions to the GAP system and at the same time giving
the author a more  official recognition of  her or  his work that  may
eventually allow   quotation  of such  a  contribution in  her  or his
publication list.   The necessity of such a  formal procedure for both
reasons has been emphazised by various people several times in private
communications and I have at least touched  upon this point at the end
of my lecture 'An invitation to Computational  Group Theory' in Galway
which is printed in the  Proceedings of that meeting  (C. M.  Campbell
et al., editors, Groups'93, Galway/St.Andrews, Cambridge UP 1995)

As done up to  now with quite  a  few programs  and other GAP  related
material, a contribution  offered to GAP is   most welcome to  be just
deposited in the 'incoming' file.  Such material will (as in the past)
not be reviewed in any way, and will remain totally under its author's
responsibility.    This   will  then   resemble the    distribution of
preprints, for which the 'incoming' file  just provides some help with
the distribution.

However a contribution  to GAP  may in  two  ways become  an  official
part of GAP:

-  it can become   part of the main  GAP  library . In  such case  the
author's name will be joined  to the list of the  authors of GAP  that
now  occurs with  the  GAP banner.   What  exactly was  written by the
author will be documented in the  respective files of the GAP library.
Further responsibility for explanations,  bug fixes,  modification etc
will be with the GAP   team which of  course will  hope for and   most
gratefully accept help by the respective author with such tasks.

- it can become a share package.  This means that the package will not
become  a part  of  the main  GAP  library, but  will   be distributed
together with GAP under the author's name (like e.g.  GRAPE or the ANU
pQ).  The responsibility for bug fixes, explanations, updates etc will
remain with the author.

These last  two categories will then be  reached by a formal procedure
of  acceptance, which, again  as  with published papers, will  involve
reviewing of the contribution and might involve a process of improving
the contribution following suggestions and help from an editor.

The  GAP Council   will function  as    the editorial  board for  this
procedure and work exactly as an editorial board of a periodical.  For
the time until GAP Headquarters move to St.  Andrews,  I will serve as
the central clearance agency for  the board, afterwards this role will
be taken over by the   team in St.  Andrews.  Contributions  submitted
for acceptance either  to the main GAP library  or as a  share package
can be sent  directly  to me or   to one of   the members of the   GAP
Council, wo will then contact me.  One  of the Council members will be
the  editor for this contribution and  may employ referees to help her
or him  with this   task.  Referees  and  editor should  evaluate both
mathematical relevance and technical soundness of the contribution and
completeness and adequacy of the documentation.  They might suggest or
demand improvements or changes before a decision on acceptance.

Contributions sent in to  be included as part  of the main GAP library
or as  a  share  package then  (again   as with  papers  submitted for
publication)   could  be  in one of    the  three states; 'submitted',
'accepted', or   'released', while contributions   to 'incoming' would
always just have the state 'deposited'.

We have to admit, that we have no experience with such a procedure and
in fact  to  the best of our   knowledge  we seem   to explore unknown
territory with   the attempt  to  set up  such   a system of  software
reviewing.    However   in   line with  our    strong  conviction that
contributions of mathematical   algorithms in  the  form of   software
should be regarded and  hence treated as contributions  to mathematics
just like papers with theorems and proofs, we think that it is worth a
try.   In  fact we   have already with  their   authors' very positive
consent started such a  refereeing  procedure for three  contributions
that are meant to eventually become share packages.

I hope that we will get  more such offers from  some of you. We intend
to give advice with the writing of larger  packages of GAP software in
a workshop. I will come back to this and some  other plans in sections
4. and 5. of this long letter.

3. The GAP Support Group.

All  of you, reading  the GAP-forum, and those  of  you having been in
correspondence with  'gap-trouble' know a  number of names  of helpful
souls who rather regularly try to answer  questions, suggest bug fixes
etc.  Most of  these belong to the 'GAP   Support Group' which  in our
opinion provides  an  important service  to the community  of users of
GAP. I  therefore  want  to  take this  opportunity  to introduce  its
present members  to you.  Of  course membership in  this Support Group
will change over  the time and  we will inform you  from  time to time
about such changes. Please understand  however that also in the future
you should  direct   your letters to   the addresses  gap-trouble  and
gap-forum, not to  the individual  members of  the  Support Group.  So
here  are  the present members,  of   whom of  course  you know Martin
Schoenert as the main architect of the system  and Steve Linton as the
person to follow him after the move of GAP to St. Andrews.

Thomas Breuer, Aachen,
Frank Celler, Aachen,
Bettina Eick, Aachen,
Volkmar Felsch, Aachen,
Alexander Hulpke, Aachen,
Steve Linton, St. Andrews,
Werner Nickel, Aachen -> St. Andrews,
Alice Niemeyer, Perth,
Martin Schoenert, Aachen,
Heiko Theissen, Aachen.


4. A workshop 'Writing GAP Packages'.

Following the  suggestion of Jean Michel in  the GAP forum, we  plan a
workshop with the above title to be held  in Aachen, which will likely
take place in the first week of September, 1996. This will be intended
for people  who have already  some experience with  programming in GAP
and have plans  to  write a  larger package,  possibly introducing new
mathematical objects.   We hope  that  for  this workshop  at least  a
public beta-release of GAP 4 will be available  so that indeed the new
features of GAP 4 will  be an issue in  this workshop. The workshop is
not meant for  newcomers to GAP.  We will  soon issue a more  detailed
announcement with the offer to register.

5. A 'European Summer of Computational Group Theory' in 1997.

As many of you  know, the conference 'Groups  St.Andrews 1997 at Bath'
will take place from 26, July to August 9,  1997  at the university of
Bath,  England. Traditionally the  'Groups St.Andrews' meetings have a
strong  component of Computational  Group   Theory.

Further from July 7 - 11, 1997  the 'British Combinatorial Conference'
will take place at  QMW, London and this  will  have some  emphasis on
computing  in combinatorics, including  the  role of Leonard Soicher's
GRAPE package.

In addition it has very  recently been decided  that  there will be  a
third   meeting on Computational Group   Theory  at the Mathematisches
Forschungsinstitut  Oberwolfach,  Germany  from  June  1  -  7,  1997,
organised by Mike  Newman and Herbert Pahlings.  (As  most of you will
know, the Groups St.   Andrews meetings and the  British Combinatorial
Conference are  open to everybody,  while Oberwolfach  meetings are by
invitation only  and     have an  upper  bound  for   the   number  of
participants).

Following a  suggestion from  Herbert  Pahlings, it is  planned to use
these meetings as cornerstones of  a 'European Summer of Computational
group theory' which in addition will feature  a number of workshops in
several places in Europe. On of them will be a workshop introducing to
the 'Use of GAP in  Research' to be  held in St. Andrews, others  will
probably deal  with   computational  aspects of  topics  such  as 'Lie
Algebras', 'Automatic   Groups', 'Representation  Theory',  or 'Use of
Groups in the Classification of Chemical Compounds'.  You should infer
from my rather vague formulation that all this is still very much in a
stage of planning.  There will be more detailed announcements later on
in the GAP forum as  well as elsewhere  as soon  as plans become  more
definite.

We also  plan  to offer hospitality at   various institutes in  Europe
during that Summer in particular for overseas visitors who want to use
the time between  some such events  for visits to  one of the  several
places on   this  old continent   that engage in   Computational Group
Theory.

Please  do not ask   me now individually for   details, to answer such
questions individually at  the present time would  be beyond of what I
can do.  However I promise to keep  you informed through the GAP forum
about further developments.

Joachim Neubueser

---------------------------------------------------------------------
Appendix: Address list of GAP Council members:


\documentstyle[11pt]{article}
\begin{document}

Professor  Michael Atkinson\\
Department of Mathematical Sciences\\
University of St.Andrews\\
North Haugh\\
St. Andrews KY16 9SS, Scotland\\
e-mail: mda@dcs.st-and.ac.uk

Professor Andrea Caranti\\
Universit\`a Degli Studi Di Trento\\
Dipartimento di Matematica\\
I-38050 Povo (Trento) ITALY\\
e-mail: caranti@science.unitn.it (Andrea Caranti)\\

Professor Gene Cooperman\\
College of Computer Science, 161CN\\
Northeastern University\\
Boston, MA 02115, USA\\
e-mail: gene@ccs.neu.edu (Gene Cooperman)\\

Dr. Derek Holt\\
Mathematics Institute\\
University of Warwick\\
Coventry, CV4 7AL, U.K.\\
e-mail: dfh@maths.warwick.ac.uk\\

Dr. Steve Linton\\
Department of Mathematical Sciences\\
University of St Andrews\\
North Haugh\\
St Andrews KY16 9SS, SCOTLAND\\
e-mail: sal@dcs.st-and.ac.uk\\

Dr. Mike Newman\\
School of Mathematical Sciences\\
Australian National University\\
Canberra ACT 0200 AUSTRALIA\\
e-mail: newman@maths.anu.edu.au\\

Professor Herbert Pahlings\\
Lehrstuhl D f"ur Mathematik\\
RWTH Aachen\\
Templergraben 64\\
52062 Aachen, \\
e-mail: h.pahlings@math.rwth.aachen.de              \\

Professor Cheryl Praeger\\
Department of Mathematics\\
University of Western Australia\\
Perth, WA 6907  Australia\\
e-mail: praeger@maths.uwa.edu.au (Cheryl Praeger)\\

Professor Edmund F. Robertson\\
Department of Mathematical Sciences\\
University of St Andrews\\
North Haugh\\
St Andrews KY16 9SS, SCOTLAND\\
e-mail: edmund@dcs.st-and.ac.uk (Edmund Robertson)\\

Professor Akos Seress\\
The Ohio State University\\
Department of Mathematics\\
231 W 18th Avenue\\
Columbus, OH 43210, USA\\
e-mail: akos@math.ohio-state.edu (Akos Seress)\\

Professor Charles R. B. Wright\\
Department of Mathematics\\
University of Oregon\\
Eugene, OR 97403, USA\\
e-mail: wright@bright.uoregon.edu (C.R.B. Wright)\\

\end{document}



