This file contains the mails sent to the GAP forum in Januar-March 1993.

Name               Email address                           Mails    Lines
Martin Schoenert   martin@bert.math.rwth-aachen.de            28     1376
Frank Celler       fceller@bert.math.rwth-aachen.de           17     1294
Joachim Neubueser  neubuese@samson.math.rwth-aachen.de        17      578
Steve Linton       sl25@cus.cam.ac.uk                         11      199
David Sibley       sibley@math.psu.edu                        10      169
Harald Boegeholz   hwb@machnix.mathematik.uni-stuttgart.de     9      295
Jacob Hirbawi      jcbhrb@cerf.net                             7      288
Ralf Dentzer       dentzer@polyhymnia.iwr.uni-heidelberg.de    7      204
Alexander Hulpke   ahulpke@bert.math.rwth-aachen.de            6      251
Thomas Breuer      sam@ernie.math.rwth-aachen.de               5      521
Jean Michel        michel@dmi.ens.fr                           5      249
Ansgar Kaup        kaup@ccucvx.unican.es                       5       58
Arnaldo Mandel     am@ime.usp.br                               4      126
John R. Neil       neil@dehn.mth.pdx.edu                       4       92
Werner Nickel      werner@pell.anu.edu.au                      3       95
Mark Short         short@jordan.csu.murdoch.edu.au             3       77
Leonard Soicher    L.H.Soicher@qmw.ac.uk                       3       39
N. S. Mendelsohn   mendel@ccu.umanitoba.ca                     3       24
Dana-Picard Noah   dana@bimacs.cs.biu.ac.il                    3       22
Dr D. L. Johnson   dlj@maths.nott.ac.uk                        3       15
Eamonn O'Brien     obrien@pell.anu.edu.au                      2       83
Bruce Kaskel       kaskel@math.berkeley.edu                    2       77
Andrea Caranti     caranti@volterra.cineca.it                  2       72
Peter Mueller      muellpe@mi.uni-erlangen.de                  2       47
Lee Schumacher     schumach@math.wisc.edu                      2       36
Derek Holt         dfh@maths.warwick.ac.uk                     2       35
Ulderico Dardano   DARDANO@matna.na.infn.it                    2       33
Borcic Boris       borbor@divsun.unige.ch                      2       24
Volkmar Felsch     felsch@samson.math.rwth-aachen.de           1      137
Ronald Biggers     rbiggers@kscsuna1.kennesaw.edu              1       48
Jane Bamblett      bamblett@maths.ox.ac.uk                     1       38
Frederick Ford     ffor@gauss.math.rochester.edu               1       34
Werenfried Spit    SPIT@vm.ci.uv.es                            1       33
Peter Webb         webb@s5.math.umn.edu                        1       31
Oliver Bonten      oli@ernie.math.rwth-aachen.de               1       27
Martin Wursthorn   pluto@mibtt1.mathematik.uni-stuttgart.de    1       23
Edward Spitznagel  C31801ST@wuvmd.wustl.edu                    1       21
Michael Smith      smith@pell.anu.edu.au                       1       20
Ted Hurley         MATHURLEY@bodkin.ucg.ie                     1       18
Keith Dennis       dennis@math.cornell.edu                     1       18
Lee Hawkins        leh@aberystwyth.ac.uk                       1       15
Meinolf Geck       geck@dmi.ens.fr                             1       14
Anton Greil        greil@guug.de                               1       14
Donald White       white@mcs.kent.edu                          1       13
Dawn Endico        dawn@math.wayne.edu                         1       10
Geoff Smith        gcs@maths.bath.ac.uk                        1        9
Francois Digne     digne@dmi.ens.fr                            1        5
Karl Brodowsky     bro@clio.iwr.uni-heidelberg.de              1        3

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



From neubuese@samson.math.rwth-aachen.de Mon Jan  4 13:27:50 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Mon, 4 Jan 93 13:27:50 +0100
Subject:    Unsolved Problems in Group Theory (Kourovka Notebook) (fwd)

In  a  recent  letter  to  the  GAP-forum,  I  mentioned  the Kourovka
Notebook.  I got the appended detailed  information  about it from Dr.
Khukhro who is presenly in  Freiburg, Germany, which hereby  I want to
make known to all members of the forum.

Happy New Year       Joachim Neubueser

========================================================================
Forwarded message:
> From khukhro@sun8.ruf.uni-freiburg.de Thu Dec 31 14:13:47 1992
> Subject: Unsolved Problems in Group Theory (Kourovka Notebook) (fwd)
> To: neubuese@samson.

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>                                                       Now in English!
>                   UNSOLVED PROBLEMS IN GROUP THEORY
>                         THE KOUROVKA NOTEBOOK
> -----------------------------------------------------------------------
>                The 12-th revised and augmented edition
>                  V.D.Mazurov and E.I.Khukhro, Editors
>              Institute of Mathematics, Novosibirsk, 1992
>                154 p. in A5 format, softcover, 20,- DM
> -----------------------------------------------------------------------
>    This collection of unsolved problems in Group Theory and close areas
> is published regularly, every 2-3 years, starting from 1965. Each new 
> edition is supplemented with new problems and brief comments on the
> solved problems from the previous editions.
>    The problems are proposed by the experts in Group Theory and close
> areas, their level varies from a Ph.D. thesis to long-standing
> well-known problems.
> Among the authors there are many prominent Russian mathematicians, such 
> as S.I.Adian, S.N.Chernikov, Yu.L.Ershov, Yu.M.Gorchakov, R.I.Grigorchuk, 
> M.I.Kargapolov, A.I.Kostrikin, A.I.Mal'cev, Yu.I.Merzliakov,
> A.Yu.Ol'shanskii, V.P.Platonov, B.I.Plotkin, V.N.Remeslennikov,
> L.A.Shemetkov, A.L.Shmel'kin,  V.P.Shunkov, A.E.Zalesskii and others.
> Having acquired internation popularity, the Kourovka Notebook contains
> also problems of R.Baer, G.Baumslag, R.Carter, J.Dixon, R.Griess,
> K.Gruenberg, B.Hartley, H.Heineken, G.Glauberman, O.Kegel,
> B.Neumann, P.Neumann, R.Phillips, C.Praeger, D.Robinson, K.Roggenkamp, 
> J.Roseblade, J.Thompson, G.Wall, B.Wehrfritz, J.Wiegold, H.Wielandt,
> J.Wilson, H.Zieschang and others.
>    Some of the problems are quickly solved due to the fact that they are
> read  by specialists from other fields of Group Theory, others wait for
> substantial breakthroughs for many years. (Of course, it is often easier
> to pose two problems than to solve one.) It is interesting to follow the
> progress in the development of Group Theory, as more and more of these
> problems become solved  (for example, now about 3/4 of the problems from
> the 1-st edition have been solved!).
>    The present book is the 12-th revised and augmented edition (1992), it
> is  now published in two versions, in Russian and in English. The English 
> version is now available for 20,- DM per copy. (This is to cover expenses
> and to improve further editions; since there are now difficulties for
> Russian mathematicians, this kind of support is vital for the further
> existence of the Kourovka Notebook.)
>    Orders (a check, 20,- DM per copy, may be enclosed)
> should be sent to
> 
>     E.I.Khukhro   (e-mail: khukhro@sun1.ruf.uni-freiburg.de 
>                    fax: (49-761)-203-2354)
>         Mathematics Institute of the Freiburg University
>         Albertstrasse, 23 b, Freiburg i.Br., D-7800,  FRG
>   
>                                                    E.I.Khukhro, V.D.Mazurov
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%   



From dentzer@polyhymnia.iwr.uni-heidelberg.de Mon Jan  4 15:25:32 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Mon, 4 Jan 93 15:25:32 +0100
Subject:    Re: GAPstones on Suns

We have some higher GAPstone figures on our Suns, I think this is due to the
gcc compiler we used to make gap, target "sun-sunos-gcc".
With the GAP option -m 2m we get in the first run of combinat.tst:


Model					GAPstones

SLC 	(20 MHz)			15272
1+  	(25 MHz)			17758
4/280 	(16 MHz)			15145
2	(40 MHz)			27888
10-20	(33 MHz)			46876


Ralf Dentzer

dentzer@kalliope.iwr.uni-heidelberg.de



From sl25@cus.cam.ac.uk Mon Jan  4 15:58:37 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Mon, 4 Jan 93 15:58:37 +0100
Subject:    Re: GAPstones on Suns 

Using the standard executable I can add
Sun IPX 	23823
Sum 4/690       23635 (Cypress CY605 processor)

Tonight I'll run it on my PC (386SX/16) and try for a new record
lowest.

	Steve



From sibley@math.psu.edu Tue Jan  5 09:14:31 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Tue, 5 Jan 93 09:14:31 +0100
Subject:    Character Tables

I have been computing some character tables using CharTablePGroup.  Is
the order of the conjugacy classes in <G>.conjugacyClasses the same as
the order of columns in the table?  The manual implies this, but does
not say it directly.  If not, how do I know which class in the group
goes with which column in the table?

Is there some way to get the (very nice) output of DisplayCharTable
directed to a file?  I've been using cut & paste to save them, but there
must be a better way.  (I realize there is a problem with what width to
use.)

What does the message

  #I TransformingPermutations: no bijection of row families

mean?  (This might not be exactly right.  It's from memory.)  I don't
see it very often, though I've been using TransformingPermutations quite
a bit, so I assume it's something unusual.



From ahulpke@bert.math.rwth-aachen.de Tue Jan  5 10:16:36 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Tue, 5 Jan 93 10:16:36 +0100
Subject:    Re: Character Tables

In his letter David Sibley asked:
> Is the order of the conjugacy classes in <G>.conjugacyClasses the same as
> the order of columns in the table?  The manual implies this, but does
> not say it directly.

The order *is* the same, though the manual is somehow evasive in this point.
All routines computing  character tables of groups (i.e. CharTablePGroup and
also the forthcoming Dixon-Algorithm) will use the order of the classes of the
group. The only requirement is, that the class of the identity *must* be in
the first position. If the classes are not yet given, the routines compute
them, and use them in the computed order.
However, be careful with SortClassesCharTable: In GAP 3.1 this will *not*
rearrange the conjugacy classes of the group, given in 'Table.group'. This
will be fixed in GAP 3.2.

> Is there some way to get the (very nice) output of DisplayCharTable
> directed to a file?

I would suggest the following routine, which will do the required task. It
is used by
  
  PrintCharTable(file,table);

or --- alternatively --- by

  PrintCharTable(file,table,width);

where width is the length of the rows of the final output device, e.g. the
printer:

    PrintCharTable := function(arg)
    local file,table,width,screensize;
      file:=arg[1];
      table:=arg[2];
      if Length(arg)>2 then
	width:=arg[3];
      else 
	# this is the standard print width 
	width:=80;
      fi;
      # get screen size
      screensize:=SizeScreen();
      # resize screen
      SizeScreen([width,screensize[2]]);
      PrintTo(file,DisplayCharTable(table));
      # resize screen to standard size
      SizeScreen(screensize);
    end;

> What does the message
> 
>   #I TransformingPermutations: no bijection of row families
> 
> mean?  (This might not be exactly right.  It's from memory.)  I don't
> see it very often, though I've been using TransformingPermutations quite
> a bit, so I assume it's something unusual.
> 
TransformingPremutations first tries to map the rows --- regarded as sets of
their elements --- of the first matrix onto the rows of the second matrix.
The existence of such a mapping is necessary for the existence of
transforming permutations.
The same observation is valid for the columns, thus the same test is done
therefore.
If one of these two tests fail --- which can be checked quite easily ---
the two matrices cannot be equivalent. This will eliminate the need to start
the (expensive) routine, trying to map the matrices onto each other.
The meaning of the printed message is just a 'false', but it is a *fast*
'false'.

I hope this helps,

		  Alexander



From martin@bert.math.rwth-aachen.de Wed Jan  6 12:00:57 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 6 Jan 93 12:00:57 +0100
Subject:    Re: GAP on OS/2 2.0

Steve Linton, who did the port of GAP to MS-DOS, wrote to me about the
subject of GAP on OS/2 2.0.

    No it won't.  The DOS extender that lets it run in a flat 32-bit
    memory model is not compatible with OS/2 at all.

    However, an OS/2 version should not be difficult to do, as OS/2
    provides a 32-bit memory model and a C compiler for it. If you can
    find someone with an OS/2 machine (at Essen maybe) it should be no
    harder than a port to another flavour of UNIX. Indeed I vaguely
    recall the OS/2 stuff claiming to be POSIX compatible, in which case
    no work at all should be needed.

        Steve

So, if there is anybody reading this forum who has OS/2 2.0, a C compiler
for it, and who is willing to try the port, contact me.  I can provide
some hints what needs to be done.

Martin

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



From oli@ernie.math.rwth-aachen.de Wed Jan  6 13:03:56 1993
From:       oli@ernie.math.rwth-aachen.de "Oliver Bonten"
Date:       Wed, 6 Jan 93 13:03:56 +0100
Subject:    Re: re commutators

In reply to a question by K. Dennis, J. Neubueser wrote:
> for all sporadic groups. Can one perhaps use character theory also for
> verifying C_2 or C_3? I have no idea,  so here is another question. If
> so, we  have plenty of charactertables  and tools for handling them in
> GAP.

I don't think it is that easy to use character theory to verify C_2 or
higher. Character theory gives results "up to conjugacy in G", which is
sufficient for C_1, but not for C_2. A character theoretic verification
of C_1 essentialy verifies that for given x_1 there is a conjugacy class
(z) in G such that x_1 is in (z^-1)(z). Clearly , C_1 follows from this.
For given x_1, x_2, there is hope to find a conjugacy class (z) such that
x_1 and x_2 both are in (z^-1)(z), but this doesn't prove C_2, because you
don't know if it is "the same z" you get this way for writing x_1 and x_2
as commutators.
 
Nevertheless, GAP has been a very useful experimental tool for finding the
conjugacy class (z) in my thesis, and for a verification of C_2 or higher,
character theory will show you which conjugacy classes may contain the
wanted element z and which can't.

Oliver Bonten

-- 
Heute hack ich, morgen crack ich, uebermorgen hol ich mir dem SysOp sein Login.
Ach wie gut dass niemand weiss, dass ich oli@math.rwth-aachen.de heiss.



From sl25@cus.cam.ac.uk Wed Jan  6 15:04:14 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Wed, 6 Jan 93 15:04:14 +0100
Subject:    Lowest GAPStone rating?

My PC (386SX/16) returns 1607 GAPStones, using GAPEXE.386 and my
stripped (comments and extra spaces removed) libraries. Has anyone
scored less?



From sam@ernie.math.rwth-aachen.de Thu Jan  7 16:17:06 1993
From:       sam@ernie.math.rwth-aachen.de "Thomas Breuer"
Date:       Thu, 7 Jan 93 16:17:06 +0100
Subject:    

In his answer to a question of David Sibley concerning some messages
printed by 'TransformingPermutations' Alexander Hulpke did not tell
the whole truth.

Two rows are regarded to be equivalent if 'Sort' makes them equal.
The equivalence classes of rows of a matrix are called its row families.

Clearly if two matrices are permutation equivalent then every row
family of the first matrix must consist of rows that are equivalent to
the rows in a family of the other matrix, and the cardinalities of these
families must be equal.  The same of course holds for the columns of
the matrices, but moreover it is also true for the restriction to every
row family of the first matrix and its corresponding family in the second
one; this might yield a finer distribution to column families, and the
program in fact computes this one.

These distributions of rows and columns are not just computed to test
some necessary conditions of permutation equivalence, in order to avoid
starting the algorithm whenever these tests fail.  They are an essential
part of the algorithm, namely they provide the translation of the
problem to find transforming permutations into a problem completely
formulated in terms of permutations.  This problem is then solved by one
of the backtrack search algorithms for permutation groups (very similar
to the algorithm for the computation of a centralizer in a given
permutation group).

Thomas Breuer



From bamblett@maths.ox.ac.uk Wed Jan 13 13:15:29 1993
From:       bamblett@maths.ox.ac.uk "Jane Bamblett"
Date:       Wed, 13 Jan 93 13:15:29 +0100
Subject:    OperationHomomorphism

While testing an implementation of an algorithm for finding the p-core of a permutation group, I came acrss the following GAP peculiarity.
Suppose we type the following GAP commands.

     gap> G := Group((1,2,3,4), (5,6,7,8));;
     gap> H1 := Operation(G, [1,2,3,4]);
     Group((1,2,3,4))
     gap> f1 := OperationHomomorphism(G, H1);;

Then, as expected, we get

     gap> Kernel(f1);
     Subgroup(Group((1,2,3,4), (5,6,7,8)), [(5,6,7,8)])

and everything looks fine.

Now suppose that we wish to be a bit twisted and let the above group G act on the set [1..10] (so that we have two fixed points) and that we define H2 and f2 via the GAP commands

     gap> H2 := Operation(G, [1,2,3,4,9,10]);
     Group((1,2,3,4))
     gap> f2 := OperationHomomorphism(G, H2);;

Then we get:

     gap> PreImages(f2, TrivialSubgroup(H2));
     Subgroup(Group((1,2,3,4), (5,6,7,8)), [(5,6,7,8), (1,2,3,4)])
     gap> Kernel(f2) = G;
     true
     gap> Image(f2, (1,2,3,4));
     (1,2,3,4)
     gap> (1,2,3,4) in Kernel(f2);
     true

- a bit peculiar?

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

Jane Bamblett



From martin@bert.math.rwth-aachen.de Wed Jan 13 18:07:27 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 13 Jan 93 18:07:27 +0100
Subject:    Re: OperationHomomorphism

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

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

    - a bit peculiar?

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

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

        K := ShallowCopy( H );

to read

        K := ShallowCopy( G );

Jane Bamblett continues:

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

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

Martin.

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



From neil@dehn.mth.pdx.edu Thu Jan 14 21:38:42 1993
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Thu, 14 Jan 93 21:38:42 +0100
Subject:    Using GAP in a PC Lab Environment

I was wondering if anyone has had any success in getting GAP to operate in
a lab environment.  I have a lab filled with 30 PC workstations and 30 Mac
workstations all running of a single Novell file server.  The PC's are all
386 machines with 4MB of memory.  When I try to run GAP, everything runs fine
until I try to define a group.  Then it just sits there for long periods of
time not doing anything.  It also is not interruptable.  Is this just a
feature of running the MSDOS version of GAP in a network environment?  If
anyone has had success using GAP off of a Novell network, I'd appreciate
hearing what you've done.

--John Neil




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Neil, Graduate Teaching Assistant           e-mail:  neil@math.mth.pdx.edu
Mathematics Department                         NeXTMail:  neil@dehn.mth.pdx.edu
Portland State University
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



From dlj@maths.nott.ac.uk Fri Jan 15 12:22:56 1993
From:       dlj@maths.nott.ac.uk "Dr D. L. Johnson"
Date:       Fri, 15 Jan 93 12:22:56 +0100
Subject:    Re:  a question to HNN extensions

Dear Gap-forum,
especially Toni. Yes, this is correct. The stable letter in an HNN-extension
appears with exponent-sum zero in every relator and so has infinite order
even in the abelianised group.

Dave Johnson



From dlj@maths.nott.ac.uk Fri Jan 15 12:30:52 1993
From:       dlj@maths.nott.ac.uk "Dr D. L. Johnson"
Date:       Fri, 15 Jan 93 12:30:52 +0100
Subject:    Re:  group theory discussion

Dear Gap-forum,
There is an electronic forum for group-theoretical questions. It is called 
the "pub" and is run by Geoff Smith at Bath, UK.

Dave Johnson



From muellpe@mi.uni-erlangen.de Fri Jan 15 17:56:44 1993
From:       muellpe@mi.uni-erlangen.de "Peter Mueller"
Date:       Fri, 15 Jan 93 17:56:44 +0100
Subject:    Primitive Groups

The list PGTable in the primitive groups library contains some useful
data about the primitive groups of degree \le 50.

In practice one often likes to know which class of the O'Nan Scott
classification a primitive group belongs to. Wouldn't it be sensible
to add this information as a further component? Additionally,
generators of one of the (at most two) minimal normal subgroups would
be fine, as GAP doesn't seem (or did I miss something?) to offer a
convenient way to compute them.

Peter

================================================================
Peter M\"uller
Math. Institut
Univ. Erlangen-N\"urnberg
Bismarckstr. 1 1/2
8520 Erlangen



From neubuese@samson.math.rwth-aachen.de Fri Jan 15 18:03:14 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Fri, 15 Jan 93 18:03:14 +0100
Subject:    Re:  group theory discussion

Dear David,
thanks for your two remarks in  the  gap-forum. In fact Geoff had also
himself mentioned pub in a letter to  the gap-forum and I for one have
asked to be  enrolled to it, but so far did not get a message from it.
If you get any, please send me a copy.

Kind regards   Joachim



From gcs@maths.bath.ac.uk Fri Jan 15 19:12:15 1993
From:       gcs@maths.bath.ac.uk "Geoff Smith"
Date:       Fri, 15 Jan 93 19:12:15 +0100
Subject:    Re: group theory discussion

PLease do not inundate Joachim with copies of 
group-pub-forum@maths.bath.ac.uk discussion.

His enrollment request disappeared down a hole somewhere. It never reached
me. He is now enrolled and has been sent recent group-pub-forum
correspondence.

Geoff Smith



From greil@guug.de Tue Jan 19 11:43:48 1993
From:       greil@guug.de "Anton Greil"
Date:       Tue, 19 Jan 93 11:43:48 +0100
Subject:    Re: group theory discussion

> 
> PLease do not inundate Joachim with copies of 
> group-pub-forum@maths.bath.ac.uk discussion.
> 
> Geoff Smith
> 

Has me question about a conjugacy problem last week to the group-pub-forum
produced such copies? Then there may be a bug somewhere in the configuration
of the two mailing-lists.

Regards, Anton Greil
greil@guug.de



From neubuese@samson.math.rwth-aachen.de Tue Jan 19 12:31:22 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 19 Jan 93 12:31:22 +0100
Subject:    Re: group theory discussion

No worry, there seems to be everything under control in the gap-forum,
I certainly was not inundated by mail.
Thanks for everybody's concern 
Joachim Neubueser



From martin@bert.math.rwth-aachen.de Thu Jan 21 13:58:10 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 21 Jan 93 13:58:10 +0100
Subject:    Re: Primitive Groups

In his article of 1993/01/15 Peter M"uller writes:
    The list PGTable in the primitive groups library contains some useful
    data about the primitive groups of degree \le 50.

    In practice one often likes to know which class of the O'Nan Scott
    classification a primitive group belongs to. Wouldn't it be sensible
    to add this information as a further component? Additionally,
    generators of one of the (at most two) minimal normal subgroups would
    be fine, as GAP doesn't seem (or did I miss something?) to offer a
    convenient way to compute them.

Several comments.

1)  Sims says in his article "Computational methods in the study of
    permutation groups" in "Computational Problems in Abstract Algebra"
    (Proceedings Oxford 67, John Leech ed.), which contains the primitive
    groups of degree <= 20:

        Any primitive group G of degree n < 60 has a unique minimal
        normal subgroup N.

    So how comes you talk about "the (at most two) minimal normal
    subgroups"?  Or am I misunderstanding something here?

2)  If the primitive group G of degree p^k has an elementary abelian
    regular normal subgroup, this is can be computed as

        Core( G, SylowSubgroup( G, p ) )

    Peter Neumann in his article "Some algorithms for computing with
    finite permutation groups" in "Proceedings of Groups - St. Andrews
    1984" (E.F. Robertson & C.M. Campbell ed.) gives a better algorithm,
    which avoids the computation of the Sylow subgroup.  But for the
    groups in GAP's primitive group library this simple approach seems to
    be ok.

3)  If the primitive group G of degree p^k < 5^5 is not of the affine
    type the socle (i.e., because of 1) the minimal normal subgroup)
    is the last term in the derived series, and can be computed as

        d := DerivedSeries( g );
        d[Length(d)];

4)  The library file 'grp/primitiv.grp' identifies the minimal normal
    subgroup, if it is again primitiv.  For example for

        g := PrimitiveGroup( 28, 11 );

    the corresponding line in 'grp/primitiv.grp' reads

        [28,     29484,  2, 01000, 2805, 2707,  "PZL(2,27)", 148,151,156,171],

    it tells us (in encoded form in the 5. column) that the minimal
    normal subgroup is 'PrimitiveGroup( 28, 5 )', and thus we get is as

        AsSubgroup( g, PrimitiveGroup( 28, 5 ) );

    If the fifth entry reads 'EABL' the minimal normal subgroup is
    elementary abelian, and thus we can apply 2).  If the fifth entry
    is empty the minimal normal subgroup is not elementary abelian and
    not primitive, and thus we should apply 3).

Hope this helps, Martin.

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



From dfh@maths.warwick.ac.uk Thu Jan 21 23:48:34 1993
From:       dfh@maths.warwick.ac.uk "Derek Holt"
Date:       Thu, 21 Jan 93 23:48:34 +0100
Subject:    Re: Primitive Groups

With reference to the recent discusssion on primitive groups, the
smallest such group (in terms of both order and degree) which has two
distinct minimal normal subgroups is in fact  A5 x A5  in its
permutation representation of degree 60 on a diagonal subgroup.

Derek Holt.



From C31801ST@wuvmd.wustl.edu Tue Jan 26 05:10:39 1993
From:       C31801ST@wuvmd.wustl.edu "Edward Spitznagel"
Date:       Tue, 26 Jan 93 05:10:39 +0100
Subject:    FactorsInt and 6th Fermat Number

I tried factoring the 6th Fermat number using the code below and
got F6 returned to me, suggesting that F6 is prime.  Since one
factor of F6 is 274177, this seems to contradict Section 10.20
of the documentation, which states that "FactorsInt is
guaranteed to find all factors less than 10^6."

           gap> FactorsInt( 2^(2^6) + 1);
           [ 18446744073709551617 ]
           gap> (2^(2^6) + 1) / 274177;
           67280421310721
           gap> quit;

I doubt that it makes any difference, but my hardware is a Turbo
Color NeXTstation running NeXTSTEP 2.1.  My version of GAP is 3.1,
obtained as gapexe.next from SAMSON.

Edward Spitznagel
Department of Mathematics
Washington University
c31801st@wuvmd.wustl.edu



From kaup@ccucvx.unican.es Tue Jan 26 14:00:12 1993
From:       kaup@ccucvx.unican.es "Ansgar Kaup"
Date:       Tue, 26 Jan 93 14:00:12 +0100
Subject:    FactorsInt and 6th Fermat Number

I tried factoring the 6th Fermat number in order to check the result that 
Edward Spitznagel got with his NeXT and FactorsInt found the correct factors.
I am using a SUN SPARC station 10 and got the executable from SAMSON aswell.
So the bug must have something to do with Edwards Hardware or is contained in
the executable obtained from SAMSON.

Ansgar Kaup
departamento de matematicas
Universidad de Cantabria, Santander
kaup@ccucvx.unican.es



From sl25@cus.cam.ac.uk Tue Jan 26 14:57:50 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Tue, 26 Jan 93 14:57:50 +0100
Subject:    Re: FactorsInt and 6th Fermat Number 

I think this problem has come up already. There was a bug in the library,
for which Martin posted a patch. The patch may well be in the 3.1 patchlevel
3 library, so I suggest you get that if you are not using it already. Otherwise
mail me directly and I'll fish out the patch from my mail logs.

	Steve Linton



From martin@bert.math.rwth-aachen.de Tue Jan 26 17:40:11 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 26 Jan 93 17:40:11 +0100
Subject:    Re: FactorsInt and 6th Fermat Number

In his e-mail message of 1993/01/26 Edward Spitznagel wrote:
    I tried factoring the 6th Fermat number using the code below and
    got F6 returned to me, suggesting that F6 is prime.  Since one
    factor of F6 is 274177, this seems to contradict Section 10.20
    of the documentation, which states that "FactorsInt is
    guaranteed to find all factors less than 10^6."

           gap> FactorsInt( 2^(2^6) + 1);
           [ 18446744073709551617 ]
           gap> (2^(2^6) + 1) / 274177;
           67280421310721
           gap> quit;

This is indeed a bug in the function 'IsPrime'.  Since 'IsPrime(2^64+1)'
returns 'true', 'Factors' doesn't even attempt to factor it.  A fix for
that bug is in the upgrade from GAP 3.1 patchlevel 2 to GAP 3.1
patchlevel 3, which is available as 'upg3r1p3.dif.Z' from
'samson.math.rwth-aachen.de'.

More about the problem (i.e., the reason why 'IsPrime' failed), can be
found in one of my e-mails to the GAP Forum, which is in the file
'forum92d.txt' (GAP Forum mails of 4th quarter 92), on
'samson.math.rwth-aachen.de' in the directory 'tmp' (not in 'pub/gap' as
the rest of GAP).

In his e-mail message of 1993/01/26 Ansgar Kaup answered

    I tried factoring the 6th Fermat number in order to check the result that 
    Edward Spitznagel got with his NeXT and FactorsInt found the correct factors.
    I am using a SUN SPARC station 10 and got the executable from SAMSON aswell.
    So the bug must have something to do with Edwards Hardware or is contained in
    the executable obtained from SAMSON.

I think the NeXT people would be quite offended by the idea that their
hardware is to blame ;-).  (Oh, and of course the executables we
distribute never have bugs.  Well, hardly ever ;-)

Martin.

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



From martin@bert.math.rwth-aachen.de Tue Jan 26 18:18:15 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 26 Jan 93 18:18:15 +0100
Subject:    GAPstones

Here is a selected list of GAPstones for various machines.
Computer     Model  MHz Memory  OS      Compiler    GAPstones   by

Atari        ST520+  8    4 MB  TOS     gcc 2.1      1168       M. Schoenert

Apollo       DN10000 ?       ?  SR10.3  ?           20625       R. Lewis

DECstation   3100   20   32 MB  Ultrix  gcc 2.2     22590       M. Schoenert
DECstation   5120   25   32 MB  Ultrix  gcc 2.2     24942       M. Schoenert

IBM PC       386SX  16       ?  DOS     djgpp 1.05   1607       S. Linton
IBM PC       386DX  33       ?  DOS     djgpp 1.05   6057       S. Rosenbrock
IBM PC       486DX  33       ?  DOS     djgpp 1.05   9948       L. Soicher
IBM PC       486DX  50   16 MB  386BSD  gcc 2.3.3   32894       M. Schoenert
IBM PC       486DX  50   16 MB  DOS     djgpp 1.09 ~32000       M. Schoenert

IBM RS6000   950   ~40    lots  AIX     cc          41691       R. Dentzer

HP           730    67  128 MB  HP-UX 8 cc          63578       M. Schoenert

NeXTstation         25       ?  Mach    ?           16484       G. Mess

Sparc        4/280  40   32 MB  SunOs   gcc 2.1     15145       R. Dentzer
SparcStation SLC     ?       ?  SunOs   ?           11962       M. Smith
SparcStation SLC     ?   12 MB  SunOS   ?           12477       D. Endico
SparcStation SLC    20   16 MB  SunOs   gcc 2.1     15272       R. Dentzer
SparcStation 1+      ?       ?  SunOs   ?           14203       W. Nickel
SparcStation 1+      ?       ?  SunOs   ?           15032       M. Smith
SparcStation 1+      ?       ?  SunOs   ?           16739       D. Sibley
SparcStation 1+     25   24 MB  SunOs   ?           17758       R. Dentzer
SparcStation ELC     ?       ?  SunOs   ?           19821       M. Smith
SparcStation IPX     ?   64 MB  SunOS   ?           23782       D. Endico
SparcStation 2       ?       ?  SunOS   ?           24013       A. Caranti
SparcStation 2      40   32 MB  SunOS   gcc 2.1     27888       R. Dentzer
SparcStation ?       ?   64 MB  SunOS   ?           39772       A. Kaup
SparcStation 10-20  33   32 MB  SunOS   gcc 2.1     47619       R. Dentzer
SparcStation 10-31   ?       ?  SunOs   ?           44917       M. Smith
SparcStation 10-30   ?       ?  SunOS   ?           48329       W. Nickel

A few remarks:

The Atari ST520+ is the slowest machine.  It is more than a factor of 50
slower than the fastest machine (a HP 730).  Note that quite a bit of
development of GAP was done on this machine (it is the one I have at
home).  Compilation (with optimization) of the entire GAP kernel takes
over 4 hours on this machine.

There is a big difference between L. Soicher's result for a 486DX33 and
our result for 486DX50.  One would expect that the 486DX50 is 50% faster,
but not that it is more that 3 times faster.  The reason is the
following.  In regular intervals (actually whenever a loop body is
executed) GAP checks whether the user wants to interrupt the computation.
Under UNIX this means checking a variable that is set by the signal
handler for '<ctr>-C'.  Unfortunatly this is not possible under DOS/GO32
(or is it? 'setcbrk' might do what we want, but the documentation of
DJGPP only says that there is such a function, not what it does).  Thus
under DOS GAP checks whether the user has pressed a key, and if so,
whether it was '<ctr>-C'.  Now checking whether a key was pressed
requires a system call ('kbhit()'), which means that GO32 (the DOS
extender) has to switch from protected mode (in which GAP runs) to real
mode (which DOS wants).  This is a *very* expensive operation.  So
expensive, that GAP 3.1 spent more than half of the time it took to
execute 'combinat.tst' switching from protected mode to real mode and
back again.  In 3.2 we have changed GAP so that only every 20th check
actually does call 'kbhit()'.  This made GAP more than a factor of 2
faster.  And the time between pressing '<ctr>-C' and GAP responding
is still small enough.

The results for SparcStations vary somewhat.  I think this has to do with
the compiler used.  GNU CC 2.x seems to be best.

The NeXTstation is actually faster than the above result would indicate.
Namely, one has to use GNU CC 2.x, instead of the compiler that comes
with the operating system, which is GNU CC 1.39 (I think).  However,
installation of GNU CC 2.x is not a trivial task (or so I am told, there
seems to be some problem with precompiled header files).

Martin.

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



From kaup@ccucvx.unican.es Wed Jan 27 10:37:43 1993
From:       kaup@ccucvx.unican.es "Ansgar Kaup"
Date:       Wed, 27 Jan 93 10:37:43 +0100
Subject:    Sorry

Sorry for not believing in executables distributed not containing bugs
but I didn't think of not-applicated updates.

Ansgar Kaup



From neil@dehn.mth.pdx.edu Wed Jan 27 17:12:23 1993
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Wed, 27 Jan 93 17:12:23 +0100
Subject:    Running GAP on MSDOS systems

A couple of weeks ago I posted to this group the problems I was experiencing
running GAP in our lab full of PC's on a Novell network.  The problem turned
out to be completely unrelated to the use of a network.  It turns out that
GAP is unable to run correctly if EMM386 is in the CONFIG.SYS file.  The
GO32 extender is incompatible with this extended memory management tool.  A
warning should perhaps be placed in the documentation warning users of this
conflict.  I have removed this device driver from the PC's in my lab and now
GAP runs perfectly (at, of course, 386-25 speed...).

--John Neil




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Neil, Graduate Teaching Assistant           e-mail:  neil@math.mth.pdx.edu
Mathematics Department                         NeXTMail:  neil@dehn.mth.pdx.edu
Portland State University
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



From martin@bert.math.rwth-aachen.de Wed Jan 27 17:52:06 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 27 Jan 93 17:52:06 +0100
Subject:    Re: Running GAP on MSDOS systems

I can't check right now, but I'm pretty certain that we run GAP with
'EMM386' in 'config.sys'.  Somewhere in the documentation for 'djgpp' it
says that you cannot use the 'noems' switch, whatever that means.  Also I
think that if GAP has problems with the memory manager it would not even
start, while you report that the problems appear once GAP tries to read a
file.  Of course if GAP now works in your lab, you may not want to
experiment further (if it ain't broke ...), on the other hand I wonder
how much memory GAP can use if you run no memory manager.  Maybe only 640
kByte, and when it needs more it starts paging (ouch)?

Martin.

PS. I have this theory about why Bill Gates is so rich.  Secretly every
programmer who makes a living from writing a program that fixes a problem
or a deficiency in MSDOS has to pay Bill Gates 10% of his income.  Well
maybe it's only 1%.

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



From sl25@cus.cam.ac.uk Fri Jan 29 16:05:28 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Fri, 29 Jan 93 16:05:28 +0100
Subject:    Re: Running GAP on MSDOS systems 

-------- 
There are two or three different programs EMM386 around. In
particular the one you get with Windows 3.00 is deficient. You
should replace it with the one that comes with DOS 5.00a. Better
still get the Quarterdeck product QEMM386.

	Steve



From neil@dehn.mth.pdx.edu Fri Jan 29 22:37:44 1993
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Fri, 29 Jan 93 22:37:44 +0100
Subject:    Re: Running GAP on MSDOS systems 

In message <m0nHxIy-00002hC@bootes.cus.cam.ac.uk> you write:
>-------- 
>
>There are two or three different programs EMM386 around. In
>particular the one you get with Windows 3.00 is deficient. You
>should replace it with the one that comes with DOS 5.00a. Better
>still get the Quarterdeck product QEMM386.
>
>	Steve
>

We were using the one which comes with DOS 5.0.  The main problem with
EMM386 (no matter who's you use) is that their behavior, particularly with
many TSR's running (as  you need to have when attached to a network), is 
extremely unreliable and unpredictable.  Problems will work just fine until
they wish to access EMM and then they crash.  Or sometimes they work reliably
for the first several calls and then crash.  We have found that in many cases
if a program is having any problems that are memory related, get rid of
whatever version of EMM386 you are using and everything will work just fine.
As far as GAP starting to page, I believe that DJGPP has it's own memory
management stuff built in to the 32-bit extender.  Thus, EMM386 is totally
unnecessary anyway.

--John Neil

PS.  386MAX causes GAP to immediately lock up upon execution.




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Neil, Graduate Teaching Assistant           e-mail:  neil@math.mth.pdx.edu
Mathematics Department                         NeXTMail:  neil@dehn.mth.pdx.edu
Portland State University
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



From dentzer@polyhymnia.iwr.uni-heidelberg.de Mon Feb  1 10:06:51 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Mon, 1 Feb 93 10:06:51 +0100
Subject:    Re: GAPstones

Just a little correction. The line
Sparc        4/280  40   32 MB  SunOs   gcc 2.1     15145       R. Dentzer

should read

Sparc        4/280  16   40 MB  SunOs   gcc 2.1     15145       R. Dentzer

i.e. the machine has 40 MB of main memory and a frequency of 16 MHz.

And as I am just at it, do the authors of "combinat.tst" know
what is mainly measured by this benchmark? From a gprof it seems
that most of the time is spent in the GAP Interpreter (>50 %)
and only very little for doing arithmetic and memory management (<5 % each).
Does this reflect time usage of typical GAP routines? What about
permutations, AG groups, finite fields, cyclotomic fields?

Thanks

Ralf Dentzer		dentzer@kalliope.iwr.uni-heidelberg.de



From martin@bert.math.rwth-aachen.de Tue Feb  2 17:22:36 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 2 Feb 93 17:22:36 +0100
Subject:    Re: Re: GAPstones

In his e-mail message of 1993/02/01 Ralf Dentzer writes:
    And as I am just at it, do the authors of "combinat.tst" know
    what is mainly measured by this benchmark? From a gprof it seems
    that most of the time is spent in the GAP Interpreter (>50 %)
    and only very little for doing arithmetic and memory management (<5 % each).
    Does this reflect time usage of typical GAP routines? What about
    permutations, AG groups, finite fields, cyclotomic fields?

It is quite difficult to say what a typical use of GAP is.  For example,
if one works with permutation groups of degree over 100, one sees an
entire different picture.  On the other hand, computations with character
tables that involve only very few irrationalities might actually show a
similar distribution (I never tried this though).

And the answer is, yes, we are aware of the specific distribution of
"combinat.tst".  But we have found that the performance reported by
"combinat.tst" is reasonably close to our ``feeling'' of how fast the
machines we have tried it on are.


Actually one can even be a bit more specific.  Here is the output of
'pixie' (the most accurate profiling tool, because it actually counts
cycles, unfortunately only available on machines with the MIPS processor)
for GAP 3.1 running "combinat.tst".  The first column contains the number
of cycles, the second the percentage of the total number of cycles, the
third the number of calls, and the fourth the name of the function.  I
have grouped the functions according to the package they belong to, and
have ommitted functions whose percentage was below 0.1%.

Interpreter (eval 22.08%, function 19.83%, statemen 14.59%)

  33595913    7.65 	   2584301 EvVar (eval.c)
   9776625    2.23 	    196075 Eq (eval.c)
   9435970    2.15 	    190798 Diff (eval.c)
   9324288    2.12 	    181912 Sum (eval.c)
   8133406    1.85 	     71330 FunShallowCopy (eval.c)
   6900221    1.57 	    188588 EvVarAss (eval.c)
   6238983    1.42 	    143309 EvAnd (eval.c)
   5070936    1.15 	    101630 EvOr (eval.c)
   2867693    0.65 	     39239 Prod (eval.c)
   2094182    0.48 	     38040 Ne (eval.c)
   1875496    0.43 	     33166 Le (eval.c)
    435759    0.10 	      6307 Mod (eval.c)

  55270007   12.59 	    250223 EvFunccall (function.c)
  28437062    6.48 	    183380 ChangeEnv (function.c)
   3205685    0.73 	     91591 EvReturn (function.c)

  38293896    8.72 	    266957 EvIf (statemen.c)
  17140123    3.90 	     53408 EvFor (statemen.c)
   8393290    1.91 	     89811 EvStatseq (statemen.c)

Memory Management (gasman 21.51%)

  33964602    7.74 	    308242 NewBag (gasman.c)
  32295304    7.36 	        10 CollectGarb (gasman.c)
  11116554    2.53 	    362625 ExitKernel (gasman.c)
   8523620    1.94 	     57558 Resize (gasman.c)
   4714125    1.07 	    362625 EnterKernel (gasman.c)
   2938674    0.67 	    186597 NrHandles (gasman.c)
    873862    0.20 	         1 InitGasman (gasman.c)

Lists (list 16.99%, vector 0.02%)

  31478498    7.17 	    379801 EvListElm (list.c)
  19866656    4.52 	    162053 EvListAss (list.c)
  13102065    2.98 	     60932 FunAppend (list.c)
   5375002    1.22 	     68101 MakeList (list.c)
   1429617    0.33 	     68077 EvMakeList (list.c)
   1249837    0.28 	     12062 FunAdd (list.c)
    946479    0.22 	      4636 PosList (list.c)

Arithmetic (integer 1.21%, rational 0.17%)

   1469833    0.33 	     24474 QuoInt (integer.c)
   1396376    0.32 	     27243 ProdInt (integer.c)
   1194533    0.27 	     16211 GcdInt (integer.c)
    524400    0.12 	      4930 SumInt (integer.c)

    423835    0.10 	      4678 QuoRat (rational.c)

Reading (scanner 1.38%, read 0.54%, indents 0.2%, system 0.54%, libc 0.87%)

   2086621    0.48 	     19636 GetSymbol (scanner.c)
   1383089    0.31 	      7972 GetIdent (scanner.c)
    924253    0.21 	     24385 PutChr (scanner.c)
    745285    0.17 	      5104 Pr (scanner.c)
    881700    0.20 	      5460 FindIdent (idents.c)
   1133070    0.26 	    226614 SyIsIntr (system.c)
    855227    0.19 	      4319 SyFgets (system.c)
   2982948    0.68 	      4317 fgets (../fgets.c)


A total of 56.5% of the running time are spent in the interpreter.

There most of the time is spent evaluating function calls ('EvFunccall'
and 'ChangeEnv').  This is because most of the functions in the
combinatorics package work in a highly recursive manner, and thus the
number of function calls is unusually high.

(Looking at the number of calls to 'ChangeEnv' (which is called twice by
'EvFunccall' for every non-internal GAP function), one sees that 91690
calls are calls to GAP functions, and the remaining 158533 are calls to
internal functions: 71330 'ShallowCopy', 60932 'Append', 12062 'Add',
5439 'Length', 4004 'Position', 2071 'IsList', 1976 'IsFunc', and 719
others.  Comparing the numbers for 'ChangeEnv' and 'EvReturn' we see that
there were 99 calls to functions which did not return anything, most
likely they are all calls to 'Sort'.  Finally note that both 'EvIf' and
'EvFor' have 'EvStatseq' inlined, i.e., they do not call 'EvStatseq' to
evaluate their bodies.  So the number of calls of 'EvStatseq' reflects
the number of calls to GAP functions that have more than a single
statement in their body.  So comparing the numbers for 'ChangeEnv' and
'EvStatseq' we see that about 1880 calls where to functions with only a
single statement in their body, e.g., functions of the form '<var> ->
<expr>'.)

'EvVar' contributes a large percentage of the total running time, simply
because it is call so often.  Improving the speed of 'EvVar' would
therefor speed up GAP quit a bit.  Unfortunately 'EvVar' is already as
minimal as it can be.

All in all the amount of time spent in the interpreter is much higher
than one would expect from other computations.  Especially the large
number of function calls is not typical.


The memory management uses 21.5% of the total running time.  288655 of
the 308242 created bags ('NewBag') are easily accounted for: 91690 from
'EvFunccall', 71330 from 'ShallowCopy', 68077 from 'MakeList', and 57558
from 'Resize' calls.  Note that the number of calls to 'Resize' is again
unusually high.

(We are thinking about a new memory manager (Ralf has actually provided a
prototype for such a memory manager).  This new memory manager will make
'NewBag' a lot faster (probably a factor of 5 or so).  'NewBag' will also
become a macro, so that it will be more difficult to see its influence in
future profiles.  'CollectGarb' will become faster (because it will use
generations), 'ExitKernel' and 'EnterKernel' will no longer be
neccessary, and the number of calls to 'NewBag' will also be reduced
(because it is called most of the time from 'CollectGarb').  So I think
that the cost for memory management for this test could be reduced to
well below 10% with this new memory manager.)

Other computations will usually spent less time in the memory management,
unless most of the objects allocated are rather small, such as in this
computation.  And of course, if the workspace is too small, so that too
many garbage collections are neccessary, the percentage of time spent in
'CollectGarb' can become arbitrarily high (I remember a Schreier Sims
computation which I once did on my Atari, where a garbage collection was
neccessary each time after allocating 20 permutations).


Now "combinat.tst" mainly works with lists (of integers), thus it is not
surprising that 17% of the total time is spent in the list package.
Especially the number of assignments to list elements is way above the
norm.

Again all in all one would expect other computations to spent less time
in the list package.  But since lists are the main data structure in GAP
almost all computations spent quite a bit of their time in this package.


The amount of time spent in the arithmetic is small.  This is because
arithmetic of immediate integers (i.e., -2^28 <= n < 2^28) is done in
'Eq', 'Sum', 'Diff', etc., without calling other functions.  What you see
in 'SumInt', etc. are only the few computations that involve large
integers (e.g., Binomial( 400, 50 )).

Other computations that involve a lot of large integers, rationals,
cyclotomics, permutations, words, etc., will probably spent most of their
time in the respective arithmetic package.


And of course the time spent reading is very small.  If you only do a
small computation with a group (where the whole library must first be
read in), this would contribute a much higher amount.


Martin.

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



From L.H.Soicher@qmw.ac.uk Thu Feb  4 15:57:23 1993
From:       L.H.Soicher@qmw.ac.uk "Leonard Soicher"
Date:       Thu, 4 Feb 93 15:57:23 +0100
Subject:    new version of GRAPE

       GRAPE  (GRaph Algorithms using PErmutation groups)
A new version of GRAPE is available via anonymous ftp from 
IP number 138.37.80.15.  It is in the pub directory in files
grape.README and grape.tar.Z. Please read grape.README.
Also, GRAPE includes some TeX documentation to get you started.
If you collect this version of GRAPE and set it up (or have problems 
setting it up), please email me to this effect.

Notes: This version of GRAPE is an improved and expanded version of 
that released in August, 1992. All known bugs are fixed: the only
bug which was not minor was in QuotientGraph, but this bug should not 
have caused incorrect results when the quotient map was a covering map 
or when the group associated with the graph to be quotiented was 
trivial.

L.H.Soicher@qmw.ac.uk



From muellpe@mi.uni-erlangen.de Sun Feb  7 18:55:03 1993
From:       muellpe@mi.uni-erlangen.de "Peter Mueller"
Date:       Sun, 7 Feb 93 18:55:03 +0100
Subject:    Normalizer doesn't normalize?

Do I misunderstand something?

gap> Parent(g)=Parent(hp);
true
gap> g=Parent(g);
true
gap> np:=Normalizer(g,hp);;
gap> IsNormal(np,hp);
false

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

gap> g;
Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,10,15), 
( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)( 2,21)
( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) )
gap> hp;
Subgroup( Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,
 10,15), ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)
( 2,21)( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ), 
[ ( 1,15,16, 5,11,13,17)( 2,18, 4,21, 9,14, 8)( 3, 6,20,19,10, 7,12), (), 
  ( 2, 9)( 3,20)( 5,11)( 7,10)( 8,14)(12,19)(13,16)(15,17)(18,21), 
  ( 1, 3,21,11,12,14)( 2, 5, 6,18,15, 7)( 4,17,20, 8,13,10)( 9,16,19) ] )
gap> quit;


Peter



From neubuese@samson.math.rwth-aachen.de Mon Feb  8 13:53:03 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Mon, 8 Feb 93 13:53:03 +0100
Subject:    Re: Normalizer doesn't normalize?

Peter Mueller writes:

> 
> Do I misunderstand something?
> 
> gap> Parent(g)=Parent(hp);
> true
> gap> g=Parent(g);
> true
> gap> np:=Normalizer(g,hp);;
> gap> IsNormal(np,hp);
> false
> 
> ================================================================
> 
> gap> g;
> Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,10,15), 
> ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)( 2,21)
> ( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) )
> gap> hp;
> Subgroup( Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,
>  10,15), ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)
> ( 2,21)( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ), 
> [ ( 1,15,16, 5,11,13,17)( 2,18, 4,21, 9,14, 8)( 3, 6,20,19,10, 7,12), (), 
>   ( 2, 9)( 3,20)( 5,11)( 7,10)( 8,14)(12,19)(13,16)(15,17)(18,21), 
>   ( 1, 3,21,11,12,14)( 2, 5, 6,18,15, 7)( 4,17,20, 8,13,10)( 9,16,19) ] )
> gap> quit;
> 
> 
> Peter
 
This bug does  not occur any more in the present GAP 3.1 and will also
not  occur in GAP  3.2  (to  be  released  *soon*!!!).  A  bug in  the
normalizer  program was  fixed  in  patchlevel  2  for  3.1,  which is
available since June  2, 1992. So the reported  bug refers most likely
to a copy of GAP that has not been corrected with the  above-mentioned
patch.

Joachim Neubueser



From dana@bimacs.cs.biu.ac.il Wed Feb 10 15:09:43 1993
From:       dana@bimacs.cs.biu.ac.il "Dana-Picard Noah"
Date:       Wed, 10 Feb 93 15:09:43 +0100
Subject:    products

I'm a very new user of GAP and try to run it on 486.
1) If H and K are two subgroups of G, what is the easiest way of
computing their product HK as a subgroup of G?
2) Does it exist some kind of tutorial for the beginner?
Thanks a lot,
Thierry Dana-Picard.



From neubuese@samson.math.rwth-aachen.de Wed Feb 10 17:00:50 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed, 10 Feb 93 17:00:50 +0100
Subject:    Re: products

Let me answer your questions:
> Subject: products
> 
> I'm a very new user of GAP and try to run it on 486.
> 1) If H and K are two subgroups of G, what is the easiest way of
> computing their product HK as a subgroup of G?
> 2) Does it exist some kind of tutorial for the beginner?
> Thanks a lot,
> Thierry Dana-Picard.

ad 1):  Usually  the notation HK for two  subgroups H and K is used to
mean the *set* of all  elements hk with h in H and  k in K.  This is a
subgroup only  if  HK  = KH.  If  this is the  case,  then the command
Closure(H,K) will compute this *subgroup* HK,  as described in section
7.17 (pages 227/8) of the manual. If HK is *not* a subgroup ( as would
alredy happen  if you  take  two  cyclic subgroups  of order 2  in the
symmetric group of degree 3) then there is *no* GAP command to compute
this set, you would have to create this *set* by a little self-written
function.

ad 2): There is  no special tutorial for GAP, however chapter 1 of the
manual,  called  "About   GAP"  (pages   37  -150)  provides  an  easy
introduction  to GAP.  Further  you may be  interested  that  a Summer
School on Computational Group  Theory using GAP as the main vehicle is
planned as part of the  'Groups 1993, Galway/St.Andrews' meeting to be
held in Galway, Ireland, August 1 to 14.

Joachim Neubueser



From caranti@volterra.cineca.it Thu Feb 11 16:00:58 1993
From:       caranti@volterra.cineca.it "Andrea Caranti"
Date:       Thu, 11 Feb 93 16:00:58 +0100
Subject:    combinat.tst

Dear gap-forum,
I just got a new Sun SparcStation 10/41, with 64MB of RAM, running under
Solaris 1.1 at 40MHz. I ran combinat.tst with the standard 4MB and got
exactly 50000 GAPstones for the first run, and 50787 for the second
one. I was using the pre-compiled GAP kernel from Aachen. I will try
to recompile GAP on the machine, and see what I get.

Yours,

A Caranti



From L.H.Soicher@qmw.ac.uk Thu Feb 11 18:31:49 1993
From:       L.H.Soicher@qmw.ac.uk "Leonard Soicher"
Date:       Thu, 11 Feb 93 18:31:49 +0100
Subject:    Blist functions

The functions  UnionBlist,  IntersectionBlist,  and  DifferenceBlist
dont't appear to be defined!

L.H.Soicher@qmw.ac.uk



From martin@bert.math.rwth-aachen.de Thu Feb 11 18:39:54 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 11 Feb 93 18:39:54 +0100
Subject:    Re: Blist functions

'UnionBlist' etc. are defined in GAP 3.2.  But 'UniteBlist' etc. are
usually better (because they don't allocate new objects).

Thanks, Martin.

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



From michel@dmi.ens.fr Fri Feb 12 13:13:17 1993
From:       michel@dmi.ens.fr "Jean Michel"
Date:       Fri, 12 Feb 93 13:13:17 +0100
Subject:    problem with empties in GAP

I hope it is not too late to ask for some small fixes for what I consider to be
a bug in the design of some gap functions. To show why I consider this feature to be a bug,
I will show some examples of programs where I had to add ugly code to get around
it -- then you can argue against me constructively by showing me how I should have
written my code.

Example 1:
  Given a list l1,..lr of integers (with no holes -- recognized as a vector by Gap)
I want to construct the list (1,..,d,l1+d,...,lr+d).
So I wrote:

  gap>shift:=function(l,d)return Concatenation([1..d],l+d);end;

  What is the problem? This does not work when l is empty: I get 

  "Error, Vectors: '+' incompatible types"

  Indeed, when asked:

  gap>IsVector([]);
  false

  Is not this wrong? The vector space of dimension 0 is a perfectly valid
  mathematical object -- How to represent its elements?

  I had to write:

  plus:=function(a,b)
   if Length(a)=0 then return a;
   elif Length(b)=0 then return b;
   else return a+b;
   fi;
   end;

  and use it in many places instead of '+' (and similarly for '-').
  Is not this ugly (and inefficient)?

Example 2:
  I need to compute an echelonized basis of the space generated by a set of vectors.
  If s is this set (represented as a list of vectors), TriangulizeMat(s) works well
  excepted when the set is empty:

  gap>TriangulizeMat([]);
  Error, ... because in the code of the function Length(mat[1]) is taken.

  Would not it be easy to fix it so that TriangulizeMat([])=[] ?

Discussion:
  these 2 examples seem to me a symptom of a wrong treatment of empties in GAP, which
  forces to add ugly and unnecessary code to handle special cases. GAP has only one
  kind of empty, the list [] (in contrast to languages like APL where an empty matrix still
  may have a shape like [0,5]). This is fine with me, but then all operations which logically
  should accept empty vectors(or matrices, or whatever...) should also accept [].
  I cannot see any big problem with IsVector([]) being true, but it being false certainly gives me
  problems.

       Jean MICHEL, D.M.I., E.N.S - Paris



From martin@bert.math.rwth-aachen.de Fri Feb 12 17:48:24 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Fri, 12 Feb 93 17:48:24 +0100
Subject:    Re: problem with empties in GAP

In his e-mail of 1993/02/12 (actually it arrived here a little bit
earlier, but not from his subscription address, so I had to stuff it into
'listserv' by hand) Jean Michel asks why GAP doesn't allow vectors of
length zero.

He writes:

    Given a list l1,..lr of integers (with no holes -- recognized as a
    vector by Gap).  I want to construct the list (1,..,d,l1+d,...,lr+d).
    So I wrote:

        gap>shift:=function(l,d)return Concatenation([1..d],l+d);end;

    What is the problem? This does not work when l is empty: I get 

        "Error, Vectors: '+' incompatible types"

Actually this  will work in GAP 3.2, but it probably should not be relied
upon to work in later releases.

He continues

    Indeed, when asked:

        gap>IsVector([]);
        false

    Is not this wrong? The vector space of dimension 0 is a perfectly valid
    mathematical object -- How to represent its elements?

I beg to differ.  The vector space of dimension 0 *over a given field* is
a perfectly valid object.  But if we represent vectors in such a vector
space by lists of length zero we have way to find the field this vector
lies in.

Why is this a problem?  Well, what is the scalar product of two empty
vectors?  Zero, of course.  But which zero?  The integer zero, or the
zero from a finite field (but of which characteristic), or the zero
polynomial over some ring?  This is basically the problem.  We have no
way to find a field for such an empty vector (and thus the zero).

He contiunes:

    Example 2:

    I need to compute an echelonized basis of the space generated by a set of
    vectors.  If s is this set (represented as a list of vectors),
    TriangulizeMat(s) works well  excepted when the set is empty:

        gap>TriangulizeMat([]);
        Error, ... because in the code of the function Length(mat[1]) is taken.

    Would not it be easy to fix it so that TriangulizeMat([])=[] ?

Yes, it would be easy to fix 'TriangulizeMat', and I see  no problem with
this.  Expect this to happen in the near future.

He continues:

    these 2 examples seem to me a symptom of a wrong treatment of empties in
    GAP, which forces to add ugly and unnecessary code to handle special
    cases. GAP has only one kind of empty, the list [] (in contrast to
    languages like APL where an empty matrix still may have a shape like
    [0,5]). This is fine with me, but then all operations which logically
    should accept empty vectors(or matrices, or whatever...) should also
    accept [].

I would formulate this slightly different (though I agree that there is
a problem).  In GAP certain information about a vector or a matrix
is simply implicit.  For example with vectors the field over which this
vector lies is derived from the entries of this vector.  This is why a
vector must have at least one entry.  Another example are matrices.
The shape of a matrix is derived from its length and the length of its
rows.  Lets for the moment assume that vectors of length zero were legal.
Then we could create a matrix of shape [5,0], namely [[],[],[],[],[]].
But we could not create a matrix of shape [0,5], because how could GAP
guess that each row has length 5, if the matrix has no rows.

Because GAP tries to read of information (the field and the dimension)
about a vector or a matrix from the entries (the elements or the rows)
such a field or matrix may not have zero length.

In spite of this problem I still think that GAP's approach is a good one.
In GAP 2.4 vectors and matrices were different datatypes, and the
neccessary conversions between lists (of lists) and vectors or matrices
were quite a pain.  In GAP 3, where everything is just a list, you have
all the powerfull list operations and functions available to apply to
vectors, matrices (and sets too).  You can simple extract elements from a
matrix with m[i][j] or change them with an assignment (which you could
not in GAP 2.4).

He continues:

    I cannot see any big problem with IsVector([]) being true,
    but it being false certainly gives me problems.

I hope I could convince that there are problems.

Martin.

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



From borbor@divsun.unige.ch Sat Feb 13 07:48:28 1993
From:       borbor@divsun.unige.ch "Borcic Boris"
Date:       Sat, 13 Feb 93 07:48:28 +0100
Subject:    GAP for MAC, new version ?

I think I recall a new version of GAP for the Macintosh
was promised maybe mid-december for maybe mid-january
by the authors of the original port.

Is it still in the works ?

Regards,

Boris Borcic
---
(12^2-55)^2-12^2*55-1=0



From smith@pell.anu.edu.au Mon Feb 15 05:00:32 1993
From:       smith@pell.anu.edu.au "Michael Smith"
Date:       Mon, 15 Feb 93 05:00:32 +0100
Subject:    Running GAP in Emacs buffer.

GAP and Emacs users:
I have just finished writing a GAP process mode for running an interactive
GAP session in an Emacs buffer. This code is based on the GAP mode of Goetz
Pfeiffer, which I modified to use comint-mode instead of shell-mode.

GAP's command completion and help are available.  Both the help and lists
of completions are shown in separate buffers from the GAP session, and help
can be evoked at any time (on any topic, defaulting to current command) by
pressing "?".

The file gap-process.el is available by anonymous ftp from pell.anu.edu.au
in directory pub/gnu/elisp.  Note that it requires the comint-mode package
by Olin Shivers to work.

Follow the instructions in the comments at the start of the file for
installation instructions.

Cheers,
Michael.



From michel@dmi.ens.fr Mon Feb 15 10:37:30 1993
From:       michel@dmi.ens.fr "Jean Michel"
Date:       Mon, 15 Feb 93 10:37:30 +0100
Subject:    Re: problem with empties in GAP

Excuse me for this long message -- I reply to the reply to my message,
and to make things celar I quote extensively both.

I said:

>>> I hope it is not too late to ask for some small fixes for what I consider
>>> to be a bug in the design of some gap functions. To show why I consider this
>>> feature to be a bug, I will show some examples of programs where I had to
>>> add ugly code to get around it -- then you can argue against me
>>> constructively by showing me how I should have written my code.

>>> Example 1:
>>>  Given a list l1,..lr of integers (with no holes -- recognized as a vector by
>>>  Gap) I want to construct the list (1,..,d,l1+d,...,lr+d).
>>>  So I wrote:
>>>
>>>  gap>shift:=function(l,d)return Concatenation([1..d],l+d);end;
>>>
>>>  What is the problem? This does not work when l is empty: I get 
>>>
>>>  "Error, Vectors: '+' incompatible types"
>>>

Martin Schoenert says:
>> Actually this  will work in GAP 3.2, but it probably should not be relied
>> upon to work in later releases.
>> 
What does this mean?

>>>  Indeed, when asked:
>>>
>>>  gap>IsVector([]);
>>>  false
>>>
>>>  Is not this wrong? The vector space of dimension 0 is a perfectly valid
>>>  mathematical object -- How to represent its elements?
>>>

Martin says
>> I beg to differ.  The vector space of dimension 0 *over a given field* is
>> a perfectly valid object.  But if we represent vectors in such a vector
>> space by lists of length zero we have way to find the field this vector
>> lies in.
>> 
>> Why is this a problem?  Well, what is the scalar product of two empty
>> vectors?  Zero, of course.  But which zero?  The integer zero, or the
>> zero from a finite field (but of which characteristic), or the zero
>> polynomial over some ring?  This is basically the problem.  We have no
>> way to find a field for such an empty vector (and thus the zero).
>> 

This answer seems to me unnecessarily confused. It seems to reinforce my
point that the design of GAP in this area has not been well thought
out. It is possible to adopt different viewpoints of the situation:

 -pure object-oriented: everything has a type, then a vector is
 necessarily a vector of something, and Martin's criticism is fully
 valid; also the design of GAP is then terribly flawed since this type
 is not explicitely present in the object vector, which is thus mostly
 unusable.

 -functional: a unique data model (list) serves a variety of purposes.
 Type information is given by context. This is the viewpoint I have
 adopted to try to make sense of the design of GAP. Then the problem
 raised by Martin does not exist: we don't have to find the type of
 an empty object, but the type the context requires, if any:
 e.g.:
 - add a (possibly empty) vector to a number:
    if the vector is nonempty, use the type of the vector's elements
    otherwise that of the number.
 - scalar product of two empty vectors: no type information given by
   context, it is reasonable to give an error. It would be very useful,
   though, to have as answer an object which could serve as zero in a
   variety of fields and rings.
 - TriangulizeMat([]):
    no type information given by context, but none required either,
    since result is empty.
 - And now the big one:
    IsVector([]):
    The context clearly requires 'true' !



From neubuese@samson.math.rwth-aachen.de Mon Feb 15 17:31:02 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Mon, 15 Feb 93 17:31:02 +0100
Subject:    Re: problem with empties in GAP

Dear Professor Michel,
I  am  answering your letter of  February the 15.th to  the GAP  forum
since Martin Schoenert is absent from  Aachen for the next two  weeks.
Let me first summarize the point of the discussion as I see it, namely
the question in how far GAP supports the interpretation of empty lists
as vectors and allows typical vector  operations with them. At the end
of today's letter you offer two different viewpoints of the situation:

First the  "pure object-oriented: everything has a type ...".  This is
clearly not the viewpoint adopted in GAP 3.1 for the interpretation of
lists as vectors, as Martin  Schoenert explained to you in his letter.
Such a  puristic  viewpoint had been tried  in  GAP  2.4  and has been
discarded  and  removed  in the transition  from  2.4 to  3.0 since we
learned by experience that it created a lot of practical problems.  In
so far it is unnecessery to state that if this was the viewpoint taken
then the design of GAP would be terrible flawed. This viewpoint is not
taken, you know it and Martin said it.

Second the "functional: a unique  data model (list) serves a varity of
purposes...". This is indeed the viewpoint presently taken in GAP, and
again Martin has explained this. Also indeed in a number of cases, GAP
does try to use  the context  in order to interpret what  an operation
should mean in situations where, from a strict  mathematical point  of
view, the operation  is not  defined.  For instance,  if  you  want to
multiply an  integer by a  finite  field element, GAP  does  return  a
finite field element although, strictly speaking, the  two factors are
from  different  domains.  All you seem to  ask for is an extension of
the  ability of GAP  to "guess" from the context what is  meant.  That
this is  indeed  all you ask for is demonstrated by the fact that  you
are willing  to allow an  error message in case of a scalar product of
two "empty vectors".  GAP did return an error message in a place where
it  disturbed you,  but in  principle the  two  places aren't all that
different.

Such request as  shown by the problems that you mention in  your first
letter is certainly reasonable  and ought to be discussed  if problems
of the commodity of using GAP have arisen as it has been the case with
you.  I do not think, however, that such  a request is a reason to use
in a  public worldwide discussion terms like you have  chosen in  your
letters,  like  talking  of "a  wrong  treatment  of  empties" or  "an
unnecessary confused answer" and the like.  While we are grateful  for
each notification  of  a  real bug,  and  while  we  appreciate  every
suggestion for the improvement of GAP, I am not willing to accept that
users of GAP use a tone  in the discussion  with us  like an impatient
teacher may (but should not) use with a dumb student.

In  detail: Martin's  answer  that  adding an integer to an empty list
will work  in GAP  3.2 but one  should not rely upon this  to work  in
later releases  means: This possibility --which will not be  mentioned
in the manual of GAP 3.2-- exists in GAP 3.2 but  the rather difficult
question how to treat such border cases as addressed by you under  the
present viewpoint  of GAP  in more generality may  find another answer
later, forced upon by further experience.

As to the possibility  of doing the  kind of operations you would like
to have with empty vectors: GAP offers you to define a new  data  type
"vector over a  fixed field and of fixed dimension" using records in a
similar way to  the  one explained in the section "About Defining  new
Group  Elements".  Of course some  functions  have  to be written  for
that, and also it has to be expected that operations for this new type
will be less efficient.  A student of Professor Schoenwaelder here has
indeed  experimented with  this in a similar  case  in order to  avoid
difficulties with the start of a recursion.

Sincerely yours
Joachim Neubueser.



From michel@dmi.ens.fr Tue Feb 16 10:33:35 1993
From:       michel@dmi.ens.fr "Jean Michel"
Date:       Tue, 16 Feb 93 10:33:35 +0100
Subject:    Re: apologies

>> Such request as  shown by the problems that you mention in  your first
>> letter is certainly reasonable  and ought to be discussed  if problems
>> of the commodity of using GAP have arisen as it has been the case with
>> you.  I do not think, however, that such  a request is a reason to use
>> in a  public worldwide discussion terms like you have  chosen in  your
>> letters,  like  talking  of "a  wrong  treatment  of  empties" or  "an
>> unnecessary confused answer" and the like.  While we are grateful  for
>> each notification  of  a  real bug,  and  while  we  appreciate  every
>> suggestion for the improvement of GAP, I am not willing to accept that
>> users of GAP use a tone  in the discussion  with us  like an impatient
>> teacher may (but should not) use with a dumb student.
>> 
I wish to apologize for the tone of my replies. I tend to write as I
speak in the heat of the discussion, and always forget that the written
word does not carry any of the verbal and gestual clues which put things
in the proper context. But, please, do not think this reflect an
inferior opinion of your ideas, on the contrary, I only become excited
when discussing exciting topics (and never ever when I speak with
someone dumb).

P.S. I also think now from your reply that my question has been fully
understood, so I wait eagerly for what you will do.

Now another small tought about GAP to make this letter a better fit for
the forum:

I have had often to write code, like: 'find all rows of a matrix where an
entry is the single non-zero in its column' where it would be very
useful to interpret boolean true as 1 and boolean false as 0, like in C:
then this particular code could be:

  Filtered(mat,List(Sum(mat,x->x<>0),y->y=1));

Actually implicit conversion is not necessary, it would be just
as good to write

  Filtered(mat,List(Sum(mat,x->Int(x<>0)),y->y=1));

if Int did the conversion job. And further, a change to GAP is
unnecessary, I can always define:

  BooltoInt:=function(b) if b then return 1 else return 0 fi;end;

But, here is my problem: since GAP is yet interpreted, not compiled,
calling a user-defined function like this is very costly. So what to do:

- can this functionality be added to Int or any other function?
- will it be possible to link to GAP functions written in C?
- will there be a compiler some day?


Best regards, Jean MICHEL



From neubuese@samson.math.rwth-aachen.de Tue Feb 16 17:13:35 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 16 Feb 93 17:13:35 +0100
Subject:    Re: your questions

Dear Professor Michel,
thank  you for  your  letter and for understanding my general point on
the discussion.

Let me first explain the state of affairs with the new version of GAP:
I have of course said for a long while that it's release is very close
but this  is now really the  case,  in  fact Thomas Breuer  and  Frank
Celler are just fixing some last known minor  bugs and inconsistencies
that were detected in running through all the examples in  the manual.
And we hope indeed that within this week GAP 3.2 will now be available
through ftp.   This means in particular  that no  major changes can be
made any more for 3.2.

Let me then come back  to the  four detailed questions at  the  end of
your letter of yesterday.

1) adding (or in fact multiplying) the elements of  a list by a number
works  also for  the empty list and returns  the empty list.  As said,
however,  this will not be part of the description in  the  manual for
the  reasons  that I explained in my last letter,  namely,  that  this
whole area  of  interpreting empty  lists  may  at  a  later stage get
revisited.

2) Thomas Breuer has  changed  'TriangulizeMat' and 'BaseMat' to  work
also for empty lists.

3) However, 'IsVector([])'  will still return 'false' for the  reasons
explained in Martin's letter.   The  problem of  changing  this  is  a
nontrivial one and just  changing this  but  then not allowing to form
the  scalar product of two empty lists  which  are recognized as legal
vectors  might confuse users  even more.  We certainly will keep  this
whole area in mind but I cannot promise that we will come up soon with
a neat solution.

Then to the questions that you asked in today's letter:

1) As you say yourself you can  make a  function 'IntBool' that allows
you to filter out all rows  of a matrix  where  an  entry  is a single
nonzero in its column. But indeed, as you say, this will not be highly
efficient. It will probably be much more efficient to write a function
that will  run  through the matrix finding  the columns with  only one
nonzero  entry.   The  reason is  that these one-line statements using
'Filtered'  and 'List' are  elegant but tend to use  too many function
calls.  As you said, function calls to GAP  functions are costly,  but
even if there was an internal function 'IntBool' doing the boolean  to
integer conversion,  the  overhead  created  by 'Filtered', 'List' and
'Sum' would probably outweight this advantage.

2)  At  present  we  certainly  are not  installing  such  a  function
'IntBool' to the kernel and  generally  speaking we hesitate to extend
the kernel unless a proven reasonable gain in efficiency forces  us to
do that.

3) The question of providing means  of linking functions written in  C
to GAP as well as  the question  of a compiler for GAP  have certainly
been discussed here and are  on the list of "dreams" for  GAP. In fact
with  respect  to  a compiler even some  first experiments  have  been
started by a student.   The linking of C functions has  been discussed
also  with  groups  outside Aachen and  if  there  are  very  definite
proposals  that people  might have  we  certainly  like to know  them.
However, both areas are nontrivial tasks and I wouldn't want to commit
myself or anybody else to  promise anything  along these  lines in the
nearer future.

With kind regards
  Joachim Neubueser



From werner@pell.anu.edu.au Tue Feb 16 22:53:33 1993
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Tue, 16 Feb 93 22:53:33 +0100
Subject:    integer vector mod integer

Dear GAP forum,

in writing some routines to deal with integer vectors modulo a positive
integer I discovered that the operation   vec mod scalar   in GAP 3.1 is
not possible:

gap> [1,2,3,4,5,6] mod 2;
Error, operations: remainder of list and integer is not defined

It is possible to replace the statement above by the following

gap> List( [1,2,3,4,5,6], x -> x mod 2 );

but at a cost. The following two statements were executed on a Sparc
station SLC.

gap> Runtime();; List( [1..60000], x -> x*2 );; Runtime()-last2;;
10167
gap> Runtime();; [1..60000]*2;; Runtime()-last2;;
1483

It would be useful to have the operation   vec mod scaler   available
for those cases where taking the remainder makes sense. For a similar
reason the operation   vec mod vec   for integer vectors is useful.
The operation would be defined componentwise. In this way one could
easily do computations in finite abelian groups. For example, adding
two vectors in the group C_2 x C_4 x C_12 could be done as follows:

gap> ([1,2,3] + [4,5,6]) mod [2,4,12];
[1,3,9]

With kind regards, Werner Nickel.

----------------------------/|-|--|-|--|------Werner-Nickel-------------------
werner@pell.anu.edu.au     /_| |\ | |  |      Mathematics Research Section
--------------------------/--|-|-\|-|_/|------Australian-National-University--



From neubuese@samson.math.rwth-aachen.de Wed Feb 17 10:06:47 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed, 17 Feb 93 10:06:47 +0100
Subject:    Re: integer vector mod integer

Lieber Herr Nickel,
Thanks for the proposal. It looks nice and worthwhile  and will be put
on the list of quite a few that we have for future releases, but since
realizing it would mean adding to  the  kernel of GAP it is definitely
too late for 3.2.

Joachim Neubueser



From ffor@gauss.math.rochester.edu Wed Feb 17 19:10:34 1993
From:       ffor@gauss.math.rochester.edu "Frederick Ford"
Date:       Wed, 17 Feb 93 19:10:34 +0100
Subject:    GAP on super/parallel computers

I have an opportunity to get some "free" time on either a super  
computer or a parallel computer. Basically, the local administrator  
is getting complaints from users about the lack of speed recently and  
I am currently the most active user on the system. He's hoping that  
getting me off the system will give him some breathing room. I've  
been running very cpu intensive GAP computations.

The super computer options are:

                  OS              C compiler
  IBM ES-9000     AIX/370         AIX/370 C compiler
  IBM RS-6000     AIX             AIX XL C compiler/6000
  Cray-YMP        UNICOS          Cray standard C compiler


The parallel computer is a Connection Machine (massively parallel I'm  
told). The OS is System V, BSD 4.3 compatible. I don't have any  
details on the C compiler version, but it's whatever Thinking  
Machines is distributing as their "standard" C compiler.

I have three questions.

1) The manual indicates that GAP compiles on the IBM RS-6000. Does  
anyone know about any of the other platforms?

2) How much faster, generally speaking, should I expect GAP to be on  
these platforms?

3) Should I opt for super or parallel computing?


Thanks,
Frederick Ford



From jcbhrb@cerf.net Thu Feb 18 00:42:25 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Thu, 18 Feb 93 00:42:25 +0100
Subject:    Class Multiplication Constants and Character claculation in GAP

gap-forum@samson.math.rwth-aachen.de
One thing that I wish GAP could do is the direct calculation of character
tables, or better yet a full set of irreducible representation matrices.
I also could not find a routine for calculating class multiplication
constants (or coefficients) from the conjugacy classes of group elements;
this would probably be my starting point in calculating characters; oddly
enough there is a routine that uses the character tables to get the class
multiplication constants but that's going in the opposite direction of what
I have in mind. Anyway here are my questions regarding this issue:

  (1) Will version 3.2 have any of the above? or should I consider
      writing my own routines with my very limitted expertise in
      gap?

  (2) If any other user has looked at this before, please pass along
      any experiences or suggestions.

  (3) As an interim solution, is there a way to identify a user defined
      group with a group which the character tables recognize:

      For example here's a group of order 48 which the character tables
      should know:

      a := AbstractGenerator("a");
      b := AbstractGenerator("b");
      c := AbstractGenerator("c");
      z := AbstractGenerator("z");
      group4a := Group(a,b,c,z);
      group4a.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2];
      group4p:=OperationCosetsFpGroup(group4a,Subgroup(group4a,[IdWord]));

      How do identify group4p to CharTable. (PS. I happen to know for this
      particular case but in general is this doable?)

  (4) When will the next version be released?
      

Any help is greatly appreciated.

Jacob Hirbawi
JcbHrb@CERF.net



From jcbhrb@cerf.net Thu Feb 18 07:03:22 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Thu, 18 Feb 93 07:03:22 +0100
Subject:    mistake in the characters of 2.S4 ?

gap-forum@samson.math.rwth-aachen.de
While we're on the subject of group characters; there seems to be
a mistake in the characters of 2.S4 . In case anyone is wondering
this all relates to John McKay's recent post on sci.math regarding
the link between the finite dicyclic groups <2,3,3>=SL(2,3), 
<2,3,4>=2.S4, <2,3,5>=2.A5 and the exceptional Lie algebras E6,E7,E8.

gap> CharTable("2.S4");
  ....
 irreducibles := 
 [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], 
   [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], 
   [ 4, -4, 0, 0, 0, 0, 1, -1 ], 
   [ 2, -2, 0, 0, E(8)+E(8)^3, -E(8)-E(8)^3, -1, 1 ], 
   [ 2, -2, 0, 0, -E(8)-E(8)^3, E(8)+E(8)^3, -1, 1 ], 
   [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], 
  ....

I could not duplicate John's constructions with the above characters
but using the table below everything seems to fit nicely:

 [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], 
   [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], 
   [ 4, -4, 0, 0, 0, 0, 1, -1 ], 
   [ 2, -2, 0, 0, E(8)^3+E(8)^5, -E(8)^3-E(8)^5, -1, 1 ], 
   [ 2, -2, 0, 0, -E(8)^3-E(8)^5, E(8)^3+E(8)^5, -1, 1 ], 
   [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], 

both tables pass the TestCharacterTable tests!

Jacob Hirbawi
JcbHrb@CERF.net



From neubuese@samson.math.rwth-aachen.de Thu Feb 18 10:03:45 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 18 Feb 93 10:03:45 +0100
Subject:    Re: GAP on super/parallel computers

Frederick Ford asks about GAP on super/parallel computers. I am  sorry
that  from  Aachen  at present  we  cannot  give  much  advice on  his
questions,  we have  not tried any of the  systems  that are mentioned
here.   I think GAP is used  on an  RS-6000  e.g. at  Essen  , perhaps
Gerhard Schneider  (formerly Essen, now Karlsruhe) can  give advice on
IBMs generally.  I  seem to  remember that the  question  of  GAP on a
supercomputer  has  been  mentioned in  the  connection  of  measuring
GAPstones, but I have not kept  that correspondence.  Perhaps somebody
from the GAP-forum has some experience. Also Martin Schoenert may have
some  information from private correspondence, but he will return from
holidays at the beginning of March only.

Generally I would not  expect too much gain from  a  parallel  machine
since there is nothing in GAP specially supporting parallel computing,
but this is pure (maybe poor) guessing. I you dare to try, we would be
interested to hear of the outcome.

Joachim Neubueser



From sam@ernie.math.rwth-aachen.de Thu Feb 18 13:41:57 1993
From:       sam@ernie.math.rwth-aachen.de "Thomas Breuer"
Date:       Thu, 18 Feb 93 13:41:57 +0100
Subject:    

Dear Mrs. and Mr. Forum,
in his message of 18 Feb 93 Jacob Hirbawi asks some questions
concerning character tables.

> One thing that I wish GAP could do is the direct calculation of character
> tables, or better yet a full set of irreducible representation matrices.

In GAP-3.1 both is possible for finite polycyclic groups $G$ with the
property that there is an abelian normal subgroup $N$ of $G$ such that
the factor group $G/N$ is supersolvable.  The GAP functions in question
are 'MatRepresentationsPGroup' and 'CharTablePGroup'.
The algorithm used is described in

U. Baum. Existenz und effiziente Konstruktion schneller
   Fouriertransformationen "uberaufl"osbarer Gruppen.
   Dissertation, Rheinische Friedrich Wilhelm Universit"at Bonn, 1991.

(An English version of this was also published in 1992, but at the moment
I don't find where.)

Jacob Hirbawi continues:

> I also could not find a routine for calculating class multiplication
> constants (or coefficients) from the conjugacy classes of group elements;
> this would probably be my starting point in calculating characters;

In GAP-3.2 there will be an implementation of the so-called Dixon-Schneider
method for the computation of character tables of finite groups.
This algorithm in fact does compute class multiplication constants,
and from that the irreducible characters.  Alexander Hulpke did this
implementation, and he could compute the tables of some large maximal
subgroups of sporadic simple groups using this program, e.g.,
the 8th maximal subgroup of the Conway group Co1, with structure
$2^{2+12}:(A_8 x S_3)$.

To compute the character table of a given group <G> in GAP-3.2 using the
Dixon-Schneider method, one will just call 'CharTable( <G> )'.  Also it
will be possible to combine this method with character theoretical tools
that were available already in GAP-3.1.
The algorithm is described in

J.D. Dixon.  High speed computations of group characters.
   Num. Math. 10, 446-450

and

G.J.A. Schneider. Dixon's Character Table Algorithm Revisited.
   J. Symbolic Computation (1990) 9, 601-606.

As for computing the representations of arbitrary groups (i.e., groups
that are not of the type required for 'CharTablePGroup'), we have no
algorithm up to now.

Jacob Hirbawi continues:

> oddly enough there is a routine that uses the character tables to get the
> class multiplication constants but that's going in the opposite direction
> of what I have in mind.

Often it is useful to compute class multiplication constants from character
tables, e.g., if the group is too large for computations.  First, the
question whether there is a class C in a group G such that G = CC can be
answered by computing class multiplication constants; for the 26
sporadic simple groups the answer is "yes", this was checked from the
character tables in

J. Neub"user, H. Pahlings, E.Cleuvers.  Each sporadic finasig G has a class
  C such that CC = G.  Abstracts AMS, 6 (34), 1984.

Second, it is often possible to prove that a group is a Galois group over
the Rationals using a theorem of Belyi, Fried, Matzat, and Thompson.
One part is the inspection of class multiplication coefficient, the other
part requires inspection of maximal subgroups of the given group.
Such calculations can be found in

H. Pahlings, Some Sporadic Groups as Galois Groups.
  Rend. Sem. Mat. Univ. Padova, Vol. 79 (1988)

and

H. Pahlings, Some Sporadic Groups as Galois Groups II.
  Rend. Sem. Mat. Univ. Padova, Vol. 82 (1989).


Jacob Hirbawi continues:

>  Anyway here are my questions regarding this issue:
> 
>   (1) Will version 3.2 have any of the above? or should I consider
>       writing my own routines with my very limitted expertise in
>       gap?
> 
>   (2) If any other user has looked at this before, please pass along
>       any experiences or suggestions.
> 
>   (3) As an interim solution, is there a way to identify a user defined
>       group with a group which the character tables recognize:
> 
>       For example here's a group of order 48 which the character tables
>       should know:
> 
>       a := AbstractGenerator("a");
>       b := AbstractGenerator("b");
>       c := AbstractGenerator("c");
>       z := AbstractGenerator("z");
>       group4a := Group(a,b,c,z);
>       group4a.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2];
>       group4p:=OperationCosetsFpGroup(group4a,Subgroup(group4a,[IdWord]));
> 
>       How do identify group4p to CharTable. (PS. I happen to know for this
>       particular case but in general is this doable?)
> 
>   (4) When will the next version be released?

As already said, the answer to the first part of (1) is "yes".      

Question (3) addresses a more general problem:  In GAP-3.1 there was no
very close connection between character tables and groups, dealing with
character tables was mainly talking about groups, not working with groups.
But of course one wants to deal with both the group and its table in many
situations.  When the table was computed from the group in GAP, there is
no problem, since the ordering of conjugacy classes in table and group are
the same.  But if one has a group, and wants to identify its classes
with the columns of a given library table (e.g., one contained in the
ATLAS of finite groups), this is not supported by GAP.  For some series
of groups there are generic character tables in GAP, and the parameters
allow to identify classes and characters.  In the future these parameters
will be added to the library tables belonging to such a series.

The answer to (4) is "tomorrow".


The second message of Jacob Hirbawi tells about a problem with library
tables.  He writes

> While we're on the subject of group characters; there seems to be
> a mistake in the characters of 2.S4 . In case anyone is wondering
> this all relates to John McKay's recent post on sci.math regarding
> the link between the finite dicyclic groups <2,3,3>=SL(2,3), 
> <2,3,4>=2.S4, <2,3,5>=2.A5 and the exceptional Lie algebras E6,E7,E8.
> 
> gap> CharTable("2.S4");
>   ....
>  irreducibles := 
>  [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], 
>    [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], 
>    [ 4, -4, 0, 0, 0, 0, 1, -1 ], 
>    [ 2, -2, 0, 0, E(8)+E(8)^3, -E(8)-E(8)^3, -1, 1 ], 
>    [ 2, -2, 0, 0, -E(8)-E(8)^3, E(8)+E(8)^3, -1, 1 ], 
>    [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], 
>   ....
> 
> I could not duplicate John's constructions with the above characters
> but using the table below everything seems to fit nicely:
> 
>  [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], 
>    [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], 
>    [ 4, -4, 0, 0, 0, 0, 1, -1 ], 
>    [ 2, -2, 0, 0, E(8)^3+E(8)^5, -E(8)^3-E(8)^5, -1, 1 ], 
>    [ 2, -2, 0, 0, -E(8)^3-E(8)^5, E(8)^3+E(8)^5, -1, 1 ], 
>    [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], 
> 
> both tables pass the TestCharacterTable tests!

Both lists of irreducible characters belong to character tables of groups
of structure 2.S4, so orthogonality relations are satisfied.  The table with
name "2.S4" in the table library is one of them, namely the table of the
involution centralizer in the Mathieu group M11.  The other table is that
of an isoclinic group, which can be got in GAP using the following
commmands.

      gap> t:= CharTable( "2.S4" );;
      gap> DisplayCharTable( t );
      2.S4
      
         2  4  4  3  2   3   3  1  1
         3  1  1  .  .   .   .  1  1
      
           1a 2a 4a 2b  8a  8b 3a 6a
        2P 1a 1a 2a 1a  4a  4a 3a 3a
        3P 1a 2a 4a 2b  8a  8b 1a 2a
      
      X.1   1  1  1  1   1   1  1  1
      X.2   1  1  1 -1  -1  -1  1  1
      X.3   2  2  2  .   .   . -1 -1
      X.4   3  3 -1  1  -1  -1  .  .
      X.5   4 -4  .  .   .   .  1 -1
      X.6   2 -2  .  .   A  -A -1  1
      X.7   2 -2  .  .  -A   A -1  1
      X.8   3  3 -1 -1   1   1  .  .
      
      A = E(8)+E(8)^3
        = ER(-2) = i2
      gap> iso:= CharTableIsoclinic( t );;
      gap> DisplayCharTable( iso );
      Isoclinic(2.S4)
      
         2  4  4  3  2   3   3  1  1
         3  1  1  .  .   .   .  1  1
      
           1a 2a 4a 4b  8a  8b 3a 6a
        2P 1a 1a 2a 2a  4a  4a 3a 3a
        3P 1a 2a 4a 4b  8b  8a 1a 2a
      
      X.1   1  1  1  1   1   1  1  1
      X.2   1  1  1 -1  -1  -1  1  1
      X.3   2  2  2  .   .   . -1 -1
      X.4   3  3 -1  1  -1  -1  .  .
      X.5   4 -4  .  .   .   .  1 -1
      X.6   2 -2  .  .   A  -A -1  1
      X.7   2 -2  .  .  -A   A -1  1
      X.8   3  3 -1 -1   1   1  .  .
      
      A = -E(8)+E(8)^3
        = -ER(2) = -r2

At the moment, the function 'CharTableIsoclinic' does this job only for
tables with underlying group of structure 2.G.2, as in this example.
Note that not only the characters may be different but also the power
maps.

Clearly it is a problem to access tables via names that do not uniquely
determine the group but this is the most convenient way to deal with the
tables that occur in the ATLAS of finite groups which serves as standard
for the table names.

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



From neubuese@samson.math.rwth-aachen.de Thu Feb 18 14:42:51 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 18 Feb 93 14:42:51 +0100
Subject:    Re: GAP for MAC, new version ?

On Feb. 13, Boris Borcic asked:
> I think I recall a new version of GAP for the Macintosh
> was promised maybe mid-december for maybe mid-january
> by the authors of the original port.
> 
> Is it still in the works ?

I am afraid a lot of promises have been made  about the new version of
GAP  coming  out  soon,  but that they have not been fulfilled is  our
fault,  not  that  of  the  group  of  people  working  with Professor
Mendelsohn in the University of Manitoba who kindly undertook the port
to  MACs.  However  after these days really the  new  version is being
released,  I hope that we will  get again  a  port to  the  MAC family
through the help of the same group of people.

Joachim Neubueser



From sl25@cus.cam.ac.uk Thu Feb 18 17:30:39 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Thu, 18 Feb 93 17:30:39 +0100
Subject:    Re: GAP on super/parallel computers 

Everything I am about to say is guesswork, and I would be delighted
to be proved wrong:

GAP is very unlikely to benefit from a massively parallel system
such as a connection machine without considerable help. In
principle, some (though not very many) of the array operations
involved in large list or permutation calculations could be speeded
up, but they would have to be VERY large before the gain exceeded
the overhead of distributing the data to the various machines. Also
the compiler is unlikely to spot any useful parallelisations in the
GAP kernel. It will be looking for floating point array calculations
and the like.

Super-computers are also usually optimised mainly for floating point
array calculations, but will probably still give you some gain on
large list, permutation and vector operations. They also usually
have basic scalar processors comparable to the fastest workstations,
and lots of real memory, both of which may help you.

Of the options you suggest, I'd recommend the RS/6000, on the
grounds of ease of porting and ease of use. The ES/9000 might be a
few times faster as would the Cray, but you'd really be wasting
their capabilities, and you'd probably have to do some work on the
porting.

I don't know what machine you're working on, but a Sun Sparcstation
1+ scores about 15000 GAPstones (see the archives of this list for
lots more ratings) and an RS6000 (possibly not the model you have in
mind) scores 41000. I would guess (pure stab in the dark) at about
100000 for the ES/9000, and perhaps 200000 on the Cray, but I could
be miles out.

Have you made sure that you can't speed up your programs by
improving algorithms, or even by recoding key steps in C? This is
usually the best choice where it's possible.

	Steve



From dawn@math.wayne.edu Thu Feb 18 22:09:52 1993
From:       dawn@math.wayne.edu "Dawn Endico"
Date:       Thu, 18 Feb 93 22:09:52 +0100
Subject:    Re: GAP on super/parallel computers

>I don't know what machine you're working on, but a Sun Sparcstation
>1+ scores about 15000 GAPstones (see the archives of this list for
>lots more ratings) and an RS6000 (possibly not the model you have in

Archives?!?  That reminds me that I've been meaning to ask whether
anyone has gap-forum archives available on a gohper server.  FTP?
 
--
Dawn Endico                       dawn@math.wayne.edu



From fceller@bert.math.rwth-aachen.de Fri Feb 19 20:11:14 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Fri, 19 Feb 93 20:11:14 +0100
Subject:    GAP 3.2

Dear Forum,
eventually we release GAP  3.2. Please  allow a few days until the FTP
servers outside Aachen mentioned below will provide the new files. The
files  "gapexe.su3",   "gapexe.st"  and  "gapexe.next"   are  not  yet
available but will be added as soon as possible.

Have fun with GAP
  Thomas Breuer, Frank Celler and Alexander Hulpke

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

Introduction
============

    GAP  is  a  system  for computational  discrete  algebra,  which we  have
    developed  with  particular  emphasis on  computational group theory, but
    which has already proved useful also in  other areas.  The name GAP is an
    acronym for *Groups, Algorithms, and Programming*.  This  (long) document
    announces the availability of GAP version 3 release 2, GAP 3.2 for short.
    It is an *advertisement* for GAP, but not a *commercial*, since  we  give
    GAP away for free.

    This document begins with the section "Announcement", which  contains the
    announcement proper.  The next section "Analyzing Rubik's Cube with  GAP"
    contains  an  extensive example.  This example is  followed by  a general
    discussion  of GAP's  capabilities  in  the section "An Overview of GAP".
    The section  "What's New in 3.2"  tells you about the new features in GAP
    3.2.   The  next  sections  "How  to  get  GAP" and "How  to install GAP"
    describe  how you can get GAP running on your computer.  Then we tell you
    about our plans for the future in the section  "The  Future of GAP".  The
    final section "The GAP Forum" introduces the GAP forum, where  interested
    users can discuss GAP related topics by e-mail messages.


Announcement
============
                                                            Il est trop tard,
                                                                  maintenant,
                                                  il sera toujours trop tard.
                                                                Heureusement!
                                                         (A. Camus, La chute)


                 ########            Lehrstuhl D fuer Mathematik
               ###    ####           RWTH Aachen
              ##         ##
             ##          #             #######            #########
            ##                        #      ##          ## #     ##
            ##           #           #       ##             #      ##
            ####        ##           ##       #             #      ##
             #####     ###           ##      ##             ##    ##
               ######### #            #########             #######
                         #                                  #
                        ##           Version 3              #
                       ###           Release 2              #
                      ## #           12 Feb 93              #
                     ##  #
                    ##   #  Alice Niemeyer, Werner Nickel,  Martin Schoenert
                   ##    #  Johannes Meier, Alex Wegner,    Thomas Bischops
                  ##     #  Frank Celler,   Juergen Mnich,  Udo Polis
                  ###   ##  Thomas Breuer,  Goetz Pfeiffer, Hans U. Besche
                   ######   Volkmar Felsch, Heiko Theissen, Alexander Hulpke
                            Ansgar Kaup,    Akos Seress


    Lehrstuhl D  f"ur Mathematik, RWTH Aachen,  announces the availability of
    GAP version 3  release 2,  or  GAP  3.2  for  short.  This  is the  first
    publicly  available  release  of   GAP  since  version  3.1,  which   was
    distributed since April 1992.


Analyzing Rubik's Cube with GAP
===============================
                                   Ideal Toy Company stated on the package of
                            the original Rubik cube that there were more than
                         three billion possible states the cube could attain.
                            It's analogous to Mac Donald's proudly announcing
                                  that they've sold more than 120 hamburgers.
                                                   (J. A. Paulos, Innumeracy)

    To show you what GAP can do a short example is probably best.  If you are
    not interested in this example skip to the  section "An Overview of GAP".

    For the example we consider the group of transformations of Rubik's magic
    cube.  If we number the faces of this cube as follows

                         +--------------+
                         |  1    2    3 |
                         |  4  top    5 |
                         |  6    7    8 |
          +--------------+--------------+--------------+--------------+
          |  9   10   11 | 17   18   19 | 25   26   27 | 33   34   35 |
          | 12  left  13 | 20 front  21 | 28 right  29 | 36  rear  37 |
          | 14   15   16 | 22   23   24 | 30   31   32 | 38   39   40 |
          +--------------+--------------+--------------+--------------+
                         | 41   42   43 |
                         | 44 bottom 45 |
                         | 46   47   48 |
                         +--------------+

    then the  group is  generated by the following  generators, corresponding
    to the six faces of the cube  (the two  semicolons tell GAP  not to print
    the result, which is identical to the input here).

      gap> cube := 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)
      > );;

    First we want to know the size of this group.

      gap> Size( cube );
      43252003274489856000

    Since this is a little bit unhandy, let us factorize this number.

      gap> Collected( Factors( last ) );
      [ [ 2, 27 ], [ 3, 14 ], [ 5, 3 ], [ 7, 2 ], [ 11, 1 ] ]

    (The result tells us that the size is 2^27 3^14 5^3 7^2 11.)

    Next let us investigate the operation of the group on the 48 points.

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

    The  first orbit contains the points at the corners, the second  those at
    the edges; clearly the group cannot move a point at a corner onto a point
    at an edge.

    So to  investigate the cube group  we first investigate  the operation on
    the corner points.  Note that  the constructed group that describes  this
    operation  will  operate  on the set   [1..24], not  on the  original set
    [1,3,17,14,8,38,9,41,19,48,22,6,30,33,43,11,46,40,24,27,25,35,16,32].

      gap> cube1 := Operation( cube, orbits[1] );
      Group( ( 1, 2, 5,12)( 3, 7,14,21)( 9,16,22,20),
             ( 1, 3, 8,18)( 4, 7,16,23)(11,17,22,12),
             ( 3, 9,19,11)( 5,13, 8,16)(12,21,15,23),
             ( 2, 6,15, 9)( 5,14,10,19)(13,21,20,24),
             ( 1, 4,10,20)( 2, 7,17,24)( 6,14,22,18),
             ( 4,11,13, 6)( 8,15,10,17)(18,23,19,24) )
      gap> Size( cube1 );
      88179840

    Now this group obviously operates transitively, but let us  test  whether
    it is also primitive.

      gap> corners := Blocks( cube1, [1..24] );
      [ [ 1, 7, 22 ], [ 2, 14, 20 ], [ 3, 12, 16 ], [ 4, 17, 18 ],
        [ 5, 9, 21 ], [ 6, 10, 24 ], [ 8, 11, 23 ], [ 13, 15, 19 ] ]

    Those eight  blocks correspond to  the eight corners of  the cube; on the
    one hand the group permutes those and on the  other hand it  permutes the
    three points at each corner cyclically.

    So the obvious thing to do is to  investigate the operation  of the group
    on the eight corners.

      gap> cube1b := Operation( cube1, corners, OnSets );
      Group( (1,2,5,3), (1,3,7,4), (3,5,8,7),
             (2,6,8,5), (1,4,6,2), (4,7,8,6) )
      gap> Size( cube1b );
      40320

    Now a permutation group of degree 8 that has order 40320 must be the full
    symmetric group S(8) on eight points.

    The next thing then  is to investigate  the  kernel  of this operation on
    blocks, i.e.,  the  subgroup of  'cube1'  of those elements that  fix the
    blocks setwise.

      gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
      gap> Factors( Size( Kernel( blockhom1 ) ) );
      [ 3, 3, 3, 3, 3, 3, 3 ]
      gap> IsElementaryAbelian( Kernel( blockhom1 ) );
      true

    We can  show that the product of  this elementary  abelian group 3^7 with
    the S(8) is semidirect by finding a complement, i.e., a subgroup that has
    trivial intersection with the kernel  and that generates 'cube1' together
    with the kernel.

      gap> cmpl1 := Stabilizer( cube1, [1,2,3,4,5,6,8,13], OnSets );;
      gap> Size( cmpl1 );
      40320
      gap> Size( Intersection( cmpl1, Kernel( blockhom1 ) ) );
      1
      gap> Closure( cmpl1, Kernel( blockhom1 ) ) = cube1;
      true

    There is even a more elegant way to show that 'cmpl1' is a complement.

      gap> IsIsomorphism( OperationHomomorphism( cmpl1, cube1b ) );
      true

    Of course,  theoretically  it is  clear  that 'cmpl1'   must  indeed be a
    complement.

    In  fact we  know that  'cube1' is a  subgroup of index 3 in  the  wreath
    product of a  cyclic 3 with S(8).  This  missing index 3 tells us that we
    do  not have total freedom in turning the  corners.  The  following tests
    show  that whenever we  turn one  corner clockwise we  must  turn another
    corner counterclockwise.

      gap> (1,7,22) in cube1;
      false
      gap> (1,7,22)(2,20,14) in cube1;
      true

    More or less the same things happen when we consider the operation of the
    cube group on the edges.

      gap> cube2 := Operation( cube, orbits[2] );;
      gap> Size( cube2 );
      980995276800
      gap> edges := Blocks( cube2, [1..24] );
      [ [ 1, 11 ], [ 2, 17 ], [ 3, 19 ], [ 4, 22 ], [ 5, 13 ], [ 6, 8 ],
        [ 7, 24 ], [ 9, 18 ], [ 10, 21 ], [ 12, 15 ], [ 14, 20 ], [ 16, 23 ] ]
      gap> cube2b := Operation( cube2, edges, OnSets );;
      gap> Size( cube2b );
      479001600
      gap> blockhom2 := OperationHomomorphism( cube2, cube2b );;
      gap> Factors( Size( Kernel( blockhom2 ) ) );
      [ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2 ]
      gap> IsElementaryAbelian( Kernel( blockhom2 ) );
      true
      gap> cmpl2 := Stabilizer(cube2,[1,2,3,4,5,6,7,9,10,12,14,16],OnSets);;
      gap> IsIsomorphism( OperationHomomorphism( cmpl2, cube2b ) );
      true

    This time we get a semidirect  product  of a 2^11 with an S(12), namely a
    subgroup of index 2 of the wreath product of a cyclic 2 with S(12).  Here
    the missing index 2 tells us again that we  do not  have total freedom in
    turning the edges.   The following tests show  that whenever  we flip one
    edge we must also flip another edge.

      gap> (1,11) in cube2;
      false
      gap> (1,11)(2,17) in cube2;
      true

    Since 'cube1' and  'cube2' are the groups  describing the actions  on the
    two orbits of 'cube', it is clear  that 'cube'  is a subdirect product of
    those  groups, i.e., a  subgroup of the direct  product.    Comparing the
    sizes  of 'cube1',  'cube2',  and  'cube' we   see that 'cube'  must be a
    subgroup of index 2 in the direct product of those two groups.

      gap> Size( cube );
      43252003274489856000
      gap> Size( cube1 ) * Size( cube2 );
      86504006548979712000

    This final missing index 2 tells us that we cannot operate on corners and
    edges totally independently.  The following  tests show that whenever  we
    exchange a  pair of  corners we must also  exchange a  pair of edges (and
    vice versa).

      gap> (17,19)(11,8)(6,25) in cube;
      false
      gap> (7,28)(18,21) in cube;
      false
      gap> (17,19)(11,8)(6,25)(7,28)(18,21) in cube;
      true

    Finally let us compute the centre of the cube group, i.e.,  the  subgroup
    of those operations that  can be performed  either before  or  after  any
    other operation with the same result.

      gap> Centre( cube );
      Subgroup( cube, [ ( 2,34)( 4,10)( 5,26)( 7,18)(12,37)(13,20)
                        (15,44)(21,28)(23,42)(29,36)(31,45)(39,47) ] )

    We  see that  the centre  contains  one  nontrivial element, namely   the
    operation that flips all 12 edges simultaneously.

    This concludes our  example.  Of course,  GAP  can do much more, and  the
    next section gives an overview   of its capabilities, but   demonstrating
    them all would take too much room.


An Overview of GAP
==================
                                                      Though this be madness,
                                                    yet there is method in't.
                                                     (W. Shakespeare, Hamlet)

    GAP consists of several parts: the kernel, the  library of functions, the
    library of groups and related data, and the documentation.

    The  *kernel* implements an automatic  memory management,  a  PASCAL-like
    programming  language,  also  called  GAP,  with  special  datatypes  for
    computations  in group theory, and an interactive programming environment
    to run programs written in the GAP programming language.

    The automatic  *memory management* allows  programmers  to concentrate on
    implementing the algorithm without  needing  to care about allocation and
    deallocation  of memory.   It   includes   a  garbage   collection   that
    automatically throws away objects that are no longer accessible.

    The GAP programming language supports a number  of datatypes for elements
    of fields.  *Integers* can be  arbitrarily large, and  are implemented in
    such  a  way that operations  with  small   integers are reasonably fast.
    Building on this large-integer  arithmetic GAP supports  *rationals*  and
    elements  from *cyclotomic  fields*.   Also GAP allows  one to  work with
    elements from *finite fields* of size (at present) at most 2^16.

    The  special datatypes of  group elements are *permutations*,  *matrices*
    over the  rationals, cyclotomic  fields, and  finite  fields,  *words  in
    abstract generators*, and *words in solvable groups*.

    GAP also contains  a very flexible  *list* datatype.  A list is  simply a
    collection of objects  that allows you to access  the components using an
    integer position.  Lists grow automatically when you add new elements  to
    them.  Lists are used to represent sets,  vectors, and matrices.  A *set*
    is represented   by a  sorted  list without  duplicates.   A   list whose
    elements all lie in a common field  is a *vector*.  A  list of vectors of
    the same length over a common field is a  *matrix*.  Since sets, vectors,
    and matrices are lists, all list operations and functions are applicable.
    You can, for example, find a certain element in a vector with the general
    function  'Position'.   There    are   also   *ranges*,  i.e., lists   of
    consecutive  integers, and  *boolean lists*,  i.e., lists containing only
    'true'  and 'false'.  Vectors, ranges,   and boolean lists  have  special
    internal representations to ensure efficient operations and memory usage.
    For example, a boolean list requires only one bit per element.

    *Records*   in GAP are   similar  to   lists,  except that accessing  the
    components of a record is done using a name instead of an index.  Records
    are used to collect objects of different types,  while lists usually only
    contain elements of one type.  Records are for example  used to represent
    groups and   other  domains; there  is  *no*  group datatype  in  the GAP
    language .  Because of this all information  that GAP knows about a group
    is also accessible to you by simply investigating the record.

    The control structures of GAP are PASCAL-like.  GAP  has *if* statements,
    *while*,  *repeat*,  and  *for* loops.  The for   loop  is  a little  bit
    uncommon in that it always loops over the elements of a  list.  The usual
    semantics can be obtained by looping over the elements of a range.  Using
    those building   blocks you can  write   *functions*.   Functions  can be
    recursive, and are first class objects in the sense that you  can collect
    functions in  lists, pass them as  arguments to other  functions and also
    return them.

    It  is important to  note  that GAP has dynamic  typing instead of static
    typing.  That means that the datatype is a property of the object, not of
    the variable.  This allows you to  write general  functions.  For example
    the generic  function that computes an orbit  can be  used to compute the
    orbit of  an  integer under a permutation group,  the  orbit of a  vector
    under a matrix group, the conjugacy class of  a group element,  and  many
    more.

    The  kernel also implements an *interactive  environment* that allows you
    to use GAP.  This environment supports debugging;  in case of  an error a
    break loop is entered in which you can investigate the problem, and maybe
    correct it  and continue.   You also have online  access  to the  manual,
    though sections  that  contain larger formulas  do not look nice   on the
    screen.

    The *library of  functions*,  simply called   library  in  the following,
    contains implementations  of various group theoretical algorithms written
    in the GAP language.  Because all the group  theoretical functions are in
    this library it is easy for you to look  at  them  to find  out  how they
    work, and change them if they do almost, but not quite, what you want.

    The whole   library is   centered around the   concept  of   domains  and
    categories.  A *domain* is a structured set, e.g., a group is a domain as
    is the ring of Gaussian integers.  Each  domain in GAP  belongs to one or
    more *categories*, which are simply sets of domains, e.g., the set of all
    groups forms a category.  The categories in which a domain lies determine
    the functions that are applicable to this domain and its elements.

    To each  domain belongs a set of  functions,  in a  so called  operations
    record, that are called by dispatchers  like 'Size'.   For example, for a
    permutation group  <G>, '<G>.operations.Size' is a  function implementing
    the Schreier Sims algorithm.  Thus  if  you have any domain  <D>,  simply
    calling 'Size( <D> )' will return the size of the domain <D>, computed by
    an  appropriate function.   Domains *inherit*  such functions from  their
    category,  unless they redefine  them.   For example,  for  a permutation
    group  <G>,  the derived subgroup will  be  computed by the generic group
    function, which computes the normal closure of  the subgroup generated by
    the commutators of the generators.

    Of course the most important category is the category of *groups*.  There
    are  about  100  functions applicable  to  groups.  These include general
    functions  such  as  'Centralizer'  and  'SylowSubgroup', functions  that
    compute series of subgroups such as 'LowerCentralSeries', a function that
    computes the whole lattice of subgroups, functions  that test  predicates
    such  as 'IsSimple',  functions that  are related  to the  operations  of
    groups  such as 'Stabilizer', and many more.  Most of these functions are
    applicable to all  groups,  e.g., permutation groups,  finite  polycyclic
    groups, factor groups, direct products of  arbitrary groups, and even new
    types of groups that you create by simply specifying how the elements are
    multiplied and inverted (actually  it is not quite so simple, but you can
    do it).

    Where  the general  functions that are applicable to  all  groups are not
    efficient enough,  we  have  tried  to  overlay them  by  more  efficient
    functions for special types of groups.  The prime example is the category
    of   *permutation   groups*,    which   overlays   'Size',    'Elements',
    'Centralizer', 'Normalizer', 'SylowSubgroup', and a few more functions by
    functions  that  employ  stabilizer chains  and  backtracking algorithms.
    Also many  of  the  functions  that  deal with operations  of groups  are
    overlayed for permutation groups for the operation of a permutation group
    on integers or lists of integers.

    Special  functions for *finitely presented  groups* include  functions to
    find the  index of  a  subgroup via a Todd-Coxeter coset  enumeration, to
    compute  the  abelian  invariants of  the  commutator  factor  group,  to
    intersect two subgroups, to find the  normalizer  of a  subgroup, to find
    all  subgroups of  small index, and to compute and simplify presentations
    for  subgroups.   Of  course it is possible  to go to a permutation group
    operating  on  the cosets  of  a subgroup and  then  to  work  with  this
    permutation group.

    For   *finite   polycyclic  groups*   a  special   kind  of  presentation
    corresponding to a  composition  series  is used.   Such  a  presentation
    implies  a  canonical  form  for the  elements  and thus allows efficient
    operations with the elements of such a group.  This  presentation is used
    to make  functions such  as 'Centralizer',  'Normalizer', 'Intersection',
    and  'ConjugacyClasses' very efficient.   GAP's  capabilities for  finite
    polycyclic groups  exceed  those of the computer system SOGOS (which  was
    developed at Lehrstuhl D f"ur Mathematik for the last decade).

    There  is  also  support for  *mappings* and *homomorphisms*.  Since they
    play such a  ubiquitous role in mathematics, it is only natural that they
    should also play an important role  in a system like GAP.   Mappings  and
    homomorphisms  are objects in  their own right in GAP.   You can apply  a
    mapping to an element of its source, multiply mappings (provided that the
    range of the first  is a  subset of  the  source of  the second),  invert
    mappings (even if what you get is  a multi-valued mapping), and perform a
    few more operations.   Important examples are  the  'NaturalHomomorphism'
    onto  a  factor group,  'OperationsHomomorphism'  mapping  a  group  that
    operates  on a set of <n> elements into the symmetric  group on [1..<n>],
    'Embeddings' into  products of groups,  'Projections'  from  products  of
    groups onto the components,  and the  general 'GroupHomomorphismByImages'
    for which you only specify the images of a set of generators.

    The  library contains a  package for handling  character tables of finite
    groups.  This  includes almost  all possibilities of the computer  system
    CAS (which was  developed  at  Lehrstuhl  D  f"ur  Mathematik in the last
    decade), and  many  new functions.  You can  compute character  tables of
    groups, or construct  character  tables  using other  tables, or  do some
    calculations  within  known  character  tables.   You  can, for  example,
    compute a list of candidates for permutation characters.  Of course there
    are  many character tables (at the moment  more than 650 ordinary tables)
    in the data library, including all those in the ATLAS of finite groups.

    For  large integers  we now  also  have a  package for *elementary number
    theory*.  There  are functions in this package to test primality,  factor
    integers of  reasonable  size,  compute the  size phi(<n>)  of the  prime
    residue group modulo an integer <n>, compute roots modulo an integer <n>,
    etc.  Also based on this there  is  a package  to do  calculations in the
    ring of Gaussian integers.

    The library  also includes a package for  *combinatorics*.  This contains
    functions to find all selections of various flavours of the elements of a
    set, e.g., 'Combinations' and 'Tuples', or the number of such selections,
    e.g., 'Binomial'.  Other functions  are related to  partitions of sets or
    integers, e.g., 'PartitionsSet' and 'RestrictedPartitions', or the number
    of   such, e.g., 'NrPartitions'    and  'Bell'.   It  also contains  some
    miscellaneous functions such as 'Fibonacci' and 'Bernoulli'.

    The *data library* at present  contains the primitive  permutation groups
    of degree up to 50  from C.  Sims, the 2-groups of size dividing 256 from
    E. O'Brien  and  M. F. Newman,  the  3-groups of size  dividing  729 from
    E. O'Brien and C. Rhodes,  the solvable  groups  of  size  up to 100 from
    M. Hall, J. K. Senior, R. Laue,  and J. Neub"user, a library of character
    tables including all of the ATLAS, and a library of tables  of  marks for
    various groups.  We plan to extend the data library with more data in the
    future.

    Together with GAP 3.2 we now distribute several *share library packages*.
    Such packages have been contributed  by other authors, but the  copyright
    remains with the author.  Currently there are three packages in the share
    library.   The *ANU PQ*  package, written by E.  O'Brien, consists of a C
    program implementing  a <p>-quotient and a <p>-group generation algorithm
    and functions to interface  this program with GAP (or  Cayley).  The *NQ*
    package, written by W.  Nickel, consists of  a C  program implementing an
    algorithm  to  compute  the  largest  nilpotent quotient  of  a  finitely
    presented group and a function to call this program from GAP.  The *Weyl*
    package, written  by M.  Geck, contains functions to compute with  finite
    Weyl   groups,   associated   (Iwahori-)  Hecke   algebras,   and   their
    representations.


What's New in 3.2
=================

    It  is  now possible to  extract  several  elements  from  a list  with a
    construct similar to  the one used to extract single elements.  This also
    works recursively,  so  that  it is  for  example possible  to extract  a
    submatrix of a matrix.  It is also possible to assign several elements to
    a list at once.

    Permutations can now operate on more than 65536 points.

    Ranges can now also have increments other than 1, i.e., a range is  now a
    dense  list  of  integers  such  that  the  difference  between  any  two
    consecutive elements is a nonzero constant.

    Strings are now also lists, namely  lists of characters, which are  a new
    builtin  datatype.   This  makes  functions  easier  to  write that  deal
    extensively with strings, such as 'DisplayCharTable'.

    GAP  now  supports  *univariate  polynomials*  over arbitrary coefficient
    rings.  Since the coefficient  ring may itself be a polynomial ring it is
    possible to create multivariate polynomial rings, though this is not very
    efficient.  Polynomials are implemented  in the GAP programming language,
    but there are supporting kernel functions to improve efficiency.

    Previously  the  entries  of  a  matrix  had  to be  among  the  built-in
    datatypes, i.e., rationals, cyclotomics, and finite field elements.  This
    restriction  has been removed, so that it is  now possible for example to
    compute with matrices whose entries are polynomials.

    There is now an  implementation of the  Dixon-Schneider algorithm,  which
    computes the character table of an arbitrary group.

    For permutation  groups  there are new functions to test if a permutation
    group is solvable,  and  if so  to find  a power-commutator presentation.
    Also there  is a  new  function  to compute  the composition series of  a
    permutation group.

    The  functions   to  compute  presentations  for  subgroups  of  finitely
    presented groups and to simplify them are new.

    There are new functions  that work with  table  of  marks, which  give  a
    compact description of the subgroup  lattice  of  a group.   For  example
    there is  a function that computes the  value of the Moebius function for
    the subgroup lattice of a group with a given table of marks.

    E. O'Brien and C. Rhodes provided  a library of 3-groups of size dividing
    729.   The character  table library  has  been extended  by  about 60 new
    ordinary tables and  about 200 new modular tables.  There is  also a data
    library that contains table of marks for various groups, e.g., McL.

    The share library packages  *ANU PQ*,  *NQ*, and  *Weyl* mentioned in the
    previous section are also new.


How to get GAP
==============
                                     Ceterum censeo:
                                       Nobody has ever paid a licence fee
                                         for using a proof
                                       that shows Sylow's subgroups to exist.
                                       Nobody should ever pay a licence fee
                                         for using a program
                                       that computes Sylow's subgroups.
                                                               (J. Neub"user)

    GAP  is distributed *free  of  charge*.  You  can obtain it via  'ftp' or
    electronic mail and give it away to your colleagues.  GAP is *not* in the
    public domain, however.  In particular you are not allowed to incorporate
    GAP or parts thereof into a commercial product.

    If you get GAP, we would appreciate it  if you could notify us,  e.g., by
    sending  a  short  e-mail  message  to  'gap@samson.math.rwth-aachen.de',
    containing your  full  name and address,  so that we have a rough idea of
    the number of users.  We also hope that this number will be  large enough
    to convince various  agencies that GAP is a project worthy of (financial)
    support.   If you publish some result that was partly obtained using GAP,
    we would  appreciate  it  if you  would cite GAP,  just as you would cite
    another paper that you  used.  Again  we  would  appreciate if  you could
    inform us about such a paper.

    We  distribute the  *full  source*  for  everything, the  C code for  the
    kernel, the GAP code for the library, and the LaTeX  code for the manual,
    which has  at present about 800 pages.  So it should be no problem to get
    GAP,  even if you have a rather uncommon system.  Of course, ports to non
    UNIX systems may require some work.   We already  have ports  for  IBM PC
    compatibles with an Intel 80386 or 80486 and for  the Atari ST.   We also
    hope to provide a port  of  GAP 3.2 to the Apple  Macintosh  in the  near
    future (there is already  a port of GAP 3.1).  Note that about 4 MByte of
    main memory and a harddisk are required to run GAP.

    GAP 3.2 can be obtained by anonymous *ftp* from the following servers.

    'samson.math.rwth-aachen.de':
            Lehrstuhl D fur Mathematik, RWTH Aachen, Germany (137.226.152.6).

    'dimacs.rutgers.edu':
            DIMACS, Rutgers, New Brunswick, New Jersey (128.6.75.16).

    'math.ucla.edu':
            Math. Dept., Univ. of California at Los Angeles (128.97.4.254).

    'wuarchive.wustl.edu':
    	    Mathematics Archives, Univ. of Tennessee (128.252.135.4,
            directory '/edu/math/source.code/group.theory/gap').

    'pell.anu.edu.au':
            Math. Research Section, Australian National Univ. (150.203.15.5).

    'ftp' to the server  *closest* to  you, login as user 'ftp' and give your
    full  e-mail  address  as password.  GAP  is in the  directory 'pub/gap'.
    Remember when you transmit  the files  to set the  file  transfer type to
    *binary image*, otherwise you will only receive unusable  garbage.  Those
    servers will always have the latest version of GAP available.

    GAP can also be obtained via *electronic mail*.  To get  one of the files
    mentioned  below  send a message to 'listserv@samson.math.rwth-aachen.de'
    containing a line  'get GAP <file-name>',  e.g., 'get  GAP src3r2.tar.Z'.
    'listserv' will reply by sending you the file as e-mail message.

    Because most files are  large  binary files they will  be  uuencoded  and
    split into  several parts,  each   at  most 64  kBytes  large.   You  can
    concatenate  the parts  by hand,  removing the mail  header, and then use
    'uudecode' to decode them.  We suggest however that you also get 'uud.c',
    which skips  the  mail headers automatically  and  is also able to fix up
    transmission errors caused by 'EBCDIC' machines.  You can also get single
    parts of a file by sending 'get GAP <file-name> <part-nr>'.

    For users in the United Kingdom with only Janet access, neither 'ftp' nor
    the mail server will work (please do *not*  try to  use the mail server).
    Please contact Derek Holt (e-mail address 'dfh@maths.warwick.ac.uk').  He
    has kindly offered us to distribute GAP in the United Kingdom.

    The 'ftp'  directory and  the 'listserv' archive   contain  the following
    files.  Please check first  which files you  need, to  avoid transferring
    those that you don't need.

    'README':               the file you are currently reading.

    GAP version 3 release 2 itself  comes in several files.   You do not need
    all of those files.  All files are 'compress'-ed 'tar' archives.

    'src3r2.tar.Z':         the *source code* for the GAP  kernel.  You  need
                            this unless you get one of the executables below.
                            This file is about 750 KBytes long.

    'lib3r2.tar.Z':         the *library of functions*.  You need this.  This
                            file is about 1000 KBytes long.

    'doc3r2.tar.Z':         the  *documentation*.  Serves  as  LaTeX   source
                            for the printed manual and  online documentation.
                            Contains further installation  information.  This
                            file is about 850 KBytes long.

    'doc3r2.dvi.Z':         the preformatted  documentation.  You  need  this
                            if you do not have a  *big*  TeX.  This  file  is
                            about 1100 KByte long.

    'grp3r2.tar.Z':         various *group libraries*.  Contains for  example
                            all primitive permutation  groups  of  degree  at
                            most 50.  This file is about 50 KByte long.

    'two3r2.tar.Z':         the library of *2-group* of  size  at  most  256.
                            This file is about 650 KByte long.

    'thr3r2.tar.Z':         the library of *3-groups* of  size at  most  729.
                            This file is about 20 KByte long.

    'tbl3r2.tar.Z':         a library of *character tables* including all  of
                            the ATLAS.  This file is about 2050 KByte long.

    'tom3r2.tar.Z':         a library of *table of marks* of various  groups.
                            This file is about 450 KByte long.

    'anupq.tar.Z':          the *ANU PQ* share library package.  This file is
                            about 350 KByte long.

    'nq.tar.Z':             the *NQ*  share  library  package.  This  file is
                            about 100 KByte long.

    'weyl.tar.Z':           the *Weyl* share library package.  This  file  is
                            about 50 KByte long.

    'src3r2.zoo', 'lib3r2.zoo', 'doc3r2.zoo', 'grp3r2.zoo'
    'tbl3r2.zoo', 'two3r2.zoo', 'thr3r2.zoo', 'tom3r2.zoo',
    'anupq.zoo',  'nq.zoo',     'weyl.zoo':
                            'zoo'  archives  containing  *exactly*  the  same
                            files as the 'compress'-ed 'tar' archives  above.
                            The advantage of 'compress'-ed 'tar'  archives is
                            that  'uncompress' and 'tar' are widely available
                            on UNIX systems.  The advantage of 'zoo' archives
                            is  that they are smaller (about  30 percent) and
                            that 'zoo' is more common on PC-s and Atari ST-s.
                            (These files may not be available on all servers)

    We  supply  executables  for  machines  that don't usually  come with a C
    compiler or machines where  the  standard  C  compiler does  not  produce
    optimal results.  If you have one of those machines it will be easier for
    you  to  get  this executable  instead  of compiling  GAP  yourself.  The
    following  executables  are  available  (again  these  files  may not  be
    available on all servers)

    'gapexe.386':           executable for IBM PC compatibles with  an  Intel
                            80386 or  80486 running MS-DOS 5.0 compiled  with
                            the GNU  C  2.2.2  compiler.   See below  for the
                            copyright.  This file is about 500 KByte long.

    'gapexe.next':          executable  for the NeXT (680?0) running NeXTstep
                            3.0  compiled  with  GNU C 2.3.3 compiler.   This
                            file is about 400 KByte long.

    'gapexe.st':            executable  for  Atari  ST  (680?0)  running  TOS
                            compiled with the GNU C compiler.  This  file  is
                            about 450 KByte long.

    'gapexe.su3':           executable for SUN 3 (680?0) running SunOS 4.0 or
                            higher compiled  with the  GNU C  compiler.  This
                            file is about 500 KByte long.

    'gapexe.su4':           executable for SUN 4 (Sparc) running SunOS 4.1 or
                            higher  compiled with the GNU  C  2.3.2 compiler.
                            This file is about 600 KByte long.

    The following support files are also available (and again these files may
    not be available on all servers)

    'compress.tar':         'compress' version 4.1.  You  need  this  program
                            to uncompress  the  compressed  tar  files.  Note
                            however, that almost all UNIX systems  these days
                            already come with an executable 'compress'.  This
                            file is about 90 KByte long.

    'patch.tar.Z':          Larry  Wall's  'patch'  program  version  2.0.2.0
                            (patchlevel 12u4).  This program  can  be used to
                            automatically  apply upgrades.   Note  that older
                            versions  of 'patch' are *not* able to understand
                            the  unified 'diff'  format  used  in the upgrade
                            files.  This file is about 70 KByte long.

    'uud.c':                'uud' version 3.4.  'uud' is much better than the
                            'uudecode' that comes  with  most  UNIX  systems.
                            This file is about 12 KByte long.

    'zoo21.tar.Z':          Rahul Dhesi's  'zoo' archiver  version  2.1.  You
                            need this  to  unpack  the  *zoo-archives*.  Note
                            that the widespread version 2.01 will *not* work.
                            This file is about 250 KByte long.

    'zooexe.386':           Executable of 'zoo' for IBM PC compatibles.  This
                            file is about 55 KByte long.

    'zooexe.st':            Executable of 'zoo' for the Atari ST.  This  file
                            is about 80 KByte long.


How to install GAP
==================

    The file  'install.tex' in 'doc3r2.tar.Z' contains extensive installation
    instructions.  If however, you are one of those  who never  read manuals,
    here is a quick installation guide.

    First for UNIX.

    Make a directory for GAP,  e.g., '~/gap/'  or  '/usr/local/lib/gap/'.

    Unpack the source  archive  'src3r2.tar.Z' into the subdirectory  'src/';
    unpack the library archive  'lib3r2.tar.Z' into the subdirectory  'lib/';
    unpack the documentation    'doc3r2.tar.Z' into the subdirectory  'doc/'.

    If you  have obtained the optional groups and character tables  libraries
    'grp3r2.tar.Z',   'tbl3r2.tar.Z',  'two3r2.tar.Z',   'thr3r2.tar.Z',  and
    'tom3r2.tar.Z',  unpack  them  into the  subdirectories  'grp/',  'tbl/',
    'two/', 'thr/', or 'tom/'.

    Change into 'src/' and execute 'make' to  see a list of possible targets;
    select a target, if in doubt use 'bsd' or 'usg', and make the kernel.

    In an appropriate directory, e.g., '~/bin/' or  '/usr/local/bin/', create
    a shell script that executes the GAP kernel.  This should look like

       exec <gap-directory>/src/gap  -m 4m  -l <gap-directory>/lib/  $*

    The option '-m' specifies the amount  of initial memory; the  option '-l'
    specifies where to find the library, if you get it wrong GAP complains

       gap: hmm, I cannot find 'lib/init.g', maybe use option '-l <libname>'?

    Change into 'doc/' and make the printed manual with the commands

       latex manual;  latex manual;  lp -dvi manual.dvi

    or something similar, according to your local custom for using LaTeX.

    Try something in GAP,  e.g., the following exercises GAP quite a bit

       gap> m11 := Group( (1,2,3,4,5,6,7,8,9,10,11), (3,7,11,8)(4,10,5,6) );;
       gap> Number( ConjugacyClasses( m11 ) );

    The result should be 10.

    Next for IBM PC compatibles with an Intel 80386 or 80486 running  MS-DOS.

    Make a directory for GAP, e.g, 'c:\gap\'.

    Put the executable 'gapexe.386' into this directory calling it 'gap.exe'.
    Unpack the library archive   'lib3r2.zoo'  into the subdirectory  'lib\';
    unpack the documentation     'doc3r2.zoo'  into the subdirectory  'doc\'.

    If  you have  obtained the optional  groups and character table libraries
    'grp3r2.zoo', 'tbl3r2.zoo', 'two3r2.zoo', 'thr3r2.zoo', and 'tom3r2.zoo',
    unpack  them into the subdirectories 'grp\', 'tbl\', 'two\',  'thr\', and
    'tom\'.

    In a directory in  your  path,  e.g.,  'c:\bin\',  create  a  batch  file
    'gap.bat' that executes the GAP kernel.  This should look like

       <gap-directory>\gap  -m 4m  -l <gap-directory>\lib\  %1 %2 %3 %4

    The option '-m' specifies the amount  of initial memory; the  option '-l'
    specifies where to find the library, if you get it wrong GAP complains

       gap: hmm, I cannot find 'lib/init.g', maybe use option '-l <libname>'?

    Add the following line to your 'autoexec.bat' file

       SET GO32TMP=<swap-file-directory>

    where <swap-file-directory> should be the directory where you want GAP to
    put the  swap  file,  e.g.,  'c:\tmp'.   The swap  file  will  be  called
    'page????.386' and  is normally removed when GAP exits.  If 'GO32TMP'  is
    not set, 'GCCTMP', 'TMP', 'TEMP' are checked (in this order).  If neither
    is  set, GAP  will not swap to  disk.  *Note  that you must reboot before
    this change in 'autoexec.bat' takes effect*.

    Change into 'doc\' and make the printed manual with the commands

       latex manual;  latex manual;  print manual.dvi

    or something similar, according to your local custom for using LaTeX.

    Try something in GAP,  e.g., the following exercises GAP quite a bit

       gap> m11 := Group( (1,2,3,4,5,6,7,8,9,10,11), (3,7,11,8)(4,10,5,6) );;
       gap> Number( ConjugacyClasses( m11 ) );

    The result should be 10.

    Note that GAP for the 386  will  use up  to 128 MByte of extended  memory
    (using XMS, VDISK memory  allocation  strategies)  or up to 128  MByte of
    expanded memory (using VCPI programs, such as QEMM  and 386MAX) and up to
    128 MByte of disk space for swapping.   Further note that GAP for the 386
    will *not* run under Windows (because it does not support DPMI).

    If you hit <ctr>-'C' the DOS  extender ('go32') catches it and aborts GAP
    immediately.  The  keys  <ctr>-'Z' and  <alt>-'C'  can be used instead to
    interupt GAP.

    The arrow keys <left>, <right>, <up>, <down>, <home>, <end>, and <delete>
    can be used for command line editing with their intuitive meaning.

    Pathnames may be  given inside GAP using either shlash ('/') or backslash
    ('\') as a separator (though '\' must be escaped in strings of course).

    The system dependent  part of GAP for the 386 ('sysdos.c') was written by
    Steve Linton (111  Ross  St.,  Cambridge,  CB1 3BS, UK,  +44 223  411661,
    'sl25@cus.cam.ac.uk').  He assignes the copyright to the Lehrstuhl D fuer
    Mathematik.  Many thanks to Steve Linton for his work.

    GAP for the 386 was compiled  with DJ Delorie's port of the Free Software
    Foundation's GNU C compiler version 2.1.  The compiler can be obtained by
    anonymous  'ftp'  from  'grape.ecs.clarkson.edu'  where   it  is  in  the
    directory 'pub/msdos/djgpp'.  Many thanks to the Free Software Foundation
    and DJ Delorie for this amazing piece of work.

    The GNU C compiler is

        Copyright (C) 1989 Free Software Foundation, Inc.
                           675 Mass Ave, Cambridge, MA 02139, USA

    under the  terms  of the GNU General Public License (GPL).  Note that the
    GNU  GPL  states  that the  mere act  of compiling  does not  affect  the
    copyright status of GAP.

    The modifications to the compiler to make it operating under  MS-DOS, the
    functions from  the standard library 'libpc.a', the  modifications of the
    functions from the standard library  'libc.a' to make  them operate under
    MS-DOS, and the DOS extender  'go32' (which is prepended to 'gapexe.386')
    are

        Copyright (C) 1991 DJ Delorie,
                           24 Kirsten Ave, Rochester NH 03867-2954, USA

    also under  the terms of the GNU GPL.  The terms of  the GPL require that
    we make the source code for 'libpc.a' available.  They can be obtained by
    writing to Steve Linton (however, it may be  easier for you to 'ftp' them
    from  'grape.ecs.clarkson.edu'  yourself).   They  also require that  GAP
    falls under the GPL too, i.e., is distributed freely,  which it basically
    does anyhow.

    The functions in 'libc.a' that GAP for the 386 uses are

        Copyright (c) 1988 Regents of the University of California.

    under the following terms

        All rights reserved.

        Redistribution and  use  in  source and  binary  forms  are permitted
        provided  that  the  above copyright notice  and  this  paragraph are
        duplicated in  all such forms and that any documentation, advertising
        materials, and other  materials related to such  distribution and use
        acknowledge  that the  software  was  developed  by the University of
        California, Berkeley.  The  name of the University may not be used to
        endorse  or  promote  products  derived  from this  software  without
        specific prior written permission.

        THIS SOFTWARE  IS  PROVIDED ``AS  IS''  AND  WITHOUT  ANY EXPRESS  OR
        IMPLIED  WARRANTIES,  INCLUDING,  WITHOUT  LIMITATION,  THE   IMPLIED
        WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.


The Future of GAP
=================
                                                 See ye not all these things?
                                                       Verily I say unto you,
                                                 there shall not be left here
                                                      one stone upon another,
                                               that shall not be thrown down.
                                                               (Matthew 24:2)

    Clearly  GAP will  contain  bugs, as  any  system of  this  size,  though
    currently we know none.   Also there are  things that we  feel  are still
    missing, and that we would like to include into GAP.  We will continue to
    improve and extend GAP.  We will release new versions quite regulary now,
    and about three or  four upgrades a year are planned.   Make sure to  get
    these, since they will in particular contain bug-fixes.

    We are committed  however,  to staying  upward compatible  from now on in
    future releases.   That means  that  everything  that works now will also
    work in those future releases.   This is different from the quite radical
    step from GAP 2.4 to GAP 3.1, in which almost everything was changed.

    Of course, we have ideas about what we want to have in future versions of
    GAP.   However  we   are  also   looking  forward  to  your  comments  or
    suggestions.


The GAP Forum
=============

    We have also established a  GAP forum, where interested users can discuss
    GAP related topics by e-mail.  In particular this  forum is for questions
    about GAP, general comments, bug  reports, and maybe bug  fixes.  We, the
    developers  of  GAP,  will  read  this  forum  and  answer questions  and
    comments, and distribute bug fixes.  Of course others are also invited to
    answer questions,  etc.  We will also announce future  releases of GAP on
    this forum.   So  in order to be informed about bugs and  their  fixes as
    well as about additions to GAP we recommend that you subscribe to the GAP
    forum.

    To  subscribe send  a  message  to  'listserv@samson.math.rwth-aachen.de'
    containing the line 'subscribe gap-forum <your-name>', where  <your-name>
    should be your  full name, not your e-mail address.   You will receive an
    acknowledgement,  and   from  then  on   all  e-mail  messages  sent   to
    'gap-forum@samson.math.rwth-aachen.de'.

    'listserv@samson.math.rwth-aachen.de'   also   accepts    the   following
    requests:  'help' for a short help on how to use 'listserv', 'unsubscribe
    gap-forum' to unsubscribe again,  'recipients gap-forum' to get a list of
    subscribers, and 'statistics gap-forum' to see  how many  e-mail messages
    each subscriber has sent so far.


If you have further questions or comments do not  hesitate to write to me
'Martin.Schoenert@Math.RWTH-Aachen.DE'.

Thank you for your attention,  Martin.

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



From sam@ernie.math.rwth-aachen.de Fri Feb 19 20:24:10 1993
From:       sam@ernie.math.rwth-aachen.de "Thomas Breuer"
Date:       Fri, 19 Feb 93 20:24:10 +0100
Subject:    

Dear Mrs. and Mr. Forum,
many things have changed from GAP-3.1 to GAP-3.2, and there are a few
cases where this means not only extensions but the possibility that a
function will cause strange results in GAP-3.2 although it worked well
in GAP-3.1.  Maybe the most nasty case is the behaviour of strings.

As said in the announcement of GAP-3.2, now strings are also lists, thus
'IsList( <str> )' yields 'true' for a string <str>.  Suppose you have a
function that shall append a suffix to strings, and whose argument can be
either a string or a list of strings, then in GAP-3.1 it may look like this.

    gap> test := function( obj )
    >     if IsList( obj ) then
    >       return List( obj, y -> ConcatenationString( y, ".suffix" ) );
    >     else
    >       return ConcatenationString( obj, ".suffix" );
    >     fi;
    >    end;;
    gap> test( "nolist" );
    "nolist.suffix"
    gap> test( [ "l", "i", "s", "t" ] );
    [ "l.suffix", "i.suffix", "s.suffix", "t.suffix" ]

In GAP-3.2 this function does not work.

    gap> test( "nolist" );
    Error, Append: <list2> must be a list at
    Append( res, str ) ... in
    ConcatenationString( y, ".suffix" ) called from
    fun( i ) called from
    List( obj, function ( y ) ... end ) called from
    test( "nolist" ) called from
    main loop
    brk> y;
    'n'
    brk> quit;
    gap> test( [ "l", "i", "s", "t" ] );
    [ "l.suffix", "i.suffix", "s.suffix", "t.suffix" ]
    gap> [ 'l', 'i', 's', 't' ];
    "list"
    gap> List( last );
    [ "l", "i", "s", "t" ]

This is because the string '"nolist"' now is a list, and 'test' tries to
concatenate its entries with the suffix; but the entries of '"nolist"'
aren't strings but characters (which are printed in single quotes).
So a string is equivalent to the list of its characters.  On the other
hand, a list of strings is not itself a string; as in GAP-3.1, the function
'List' returns for a string the list of strings containing single letters.

Of course this is not the real problem, the solution is simply to ask for
the more special case of being a string first.  But there is a problem, and
as everybody will suspect who read the messages to the GAP forum last week,
it is a problem with empties.

    gap> IsList( "" ); IsString( "" );
    true
    true
    gap> IsList( [] ); IsString( [] );
    true
    true
    gap> [] = "";
    true

(By the way, what should the function 'test' defined above return in case
of input '""' or '[]'?  In GAP-3.1 there was a well-defined difference.)
Empty string '""' and empty list '[]' are the same now, with one exception:
In contrary to nonempty lists of characters, the empty list is not converted 
into a string, it is printed as '[  ]'.  And printing one of these objects
is the problem.  Suppose you want to write a program that prints strings
enclosed in '"', and prints other objects as they are printed by 'Print',
in GAP-3.1 this function worked.

    gap> MyPrint := function( obj )
    >      if IsString( obj ) then
    >        Print( "\"", obj, "\"\n" );
    >      else
    >        Print( obj, "\n" );
    >      fi;
    >    end;;
    gap> MyPrint( [] );
    "[  ]"
    gap> MyPrint( "" );
    ""

We want the empty list to be printed as '[  ]', and the empty string as '""',
so we must be able to distinguish the two objects.  The only solution is to
ask for the information that also GAP-3.2 uses to distinguish them.
This can be done using the function 'TYPE' that returns '"string"' for '""',
and '"list"' for '[]'.  Note that this is one of the VERY FEW situations
where an undocumented function like 'TYPE' is of interest for the user,
normally one should avoid using such functions.

    gap> MyPrint := function( obj )
    >      if IsString( obj ) and TYPE( obj ) = "string" then
    >        Print( "\"", obj, "\"\n" );
    >      else
    >        Print( obj, "\n" );
    >      fi;
    >    end;;
    gap> MyPrint( [] );
    [  ]
    gap> MyPrint( "" );
    ""

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



From jcbhrb@cerf.net Mon Feb 22 07:28:27 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Mon, 22 Feb 93 07:28:27 +0100
Subject:    Direct character calculation

gap-forum@samson.math.rwth-aachen.de
Just a couple of comments in regards to my question last week about the
direct calculation of characters. First: many thanks to Thomas Breuer 
for a great answer; now I am tempted to bother the forum with more 
questions :-) . Second I have just finished installing gap3.2 on a 
DEC Ultrix workstation and on a PC. It looks fantastic! it took just a
few minutes on the PC to do the calculations below for the characters 
of <2,3,4> and <2,3,5> -- it took the DEC 3100 a bit longer to do the same.

  a := AbstractGenerator("a");
  b := AbstractGenerator("b");
  c := AbstractGenerator("c");
  z := AbstractGenerator("z");
  g4 := Group(a,b,c,z);
  g5 := Group(a,b,c,z);
  g4.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2];
  g5.relators := [a^2*z^-1,b^3*z^-1,c^5*z^-1,a*b*c*z^-1,z^2];
  group4:=OperationCosetsFpGroup(g4,Subgroup(g4,[IdWord]));
  group5:=OperationCosetsFpGroup(g5,Subgroup(g5,[IdWord]));
  chr4 := CharTable(group4);
  chr5 := CharTable(group5);

  DisplayCharTable(chr4);


     2  4  2  1   3  4   3  1  3
     3  1  .  1   .  1   .  1  .

       1a 4a 6a  8a 2a  8b 3a 4b
    2P 1a 2a 3a  4b 1a  4b 3a 2a
    3P 1a 4a 2a  8b 2a  8a 1a 4b
    5P 1a 4a 6a  8b 2a  8a 3a 4b
    7P 1a 4a 6a  8a 2a  8b 3a 4b

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

  A = -E(8)+E(8)^3
    = -ER(2) = -r2
  DisplayCharTable(chr5);


     2  3  2  1   1  3   1  1   1   1
     3  1  .  1   .  1   .  1   .   .
     5  1  .  .   1  1   1  .   1   1

       1a 4a 6a 10a 2a  5a 3a  5b 10b
    2P 1a 2a 3a  5b 1a  5b 3a  5a  5a
    3P 1a 4a 2a 10b 2a  5b 1a  5a 10a
    5P 1a 4a 6a  2a 2a  1a 3a  1a  2a
    7P 1a 4a 6a 10b 2a  5b 3a  5a 10a

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

  A = -E(5)^2-E(5)^3
    = (1+ER(5))/2 = 1+b5

Thanks to all the developers for a great tool.

Jacob Hirbawi
JcbHrb@CERF.net



From sl25@cus.cam.ac.uk Tue Feb 23 09:17:50 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Tue, 23 Feb 93 09:17:50 +0100
Subject:    Change List

Is there a comprehensive list of changes from 3.1 to 3.2?
I've seen the "what's new" list in the announcement, but I'd be
interested in a more detailed list.

		Steve



From schumach@math.wisc.edu Tue Feb 23 09:21:36 1993
From:       schumach@math.wisc.edu "Lee Schumacher"
Date:       Tue, 23 Feb 93 09:21:36 +0100
Subject:    garbage collection

I've been using gap with the -g option, so I have some idea
what's going on during long computations.  Does anyone know
what the performance penalty is ?

  thanks,  Lee Schumacher



From mendel@ccu.umanitoba.ca Tue Feb 23 09:25:40 1993
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Tue, 23 Feb 93 09:25:40 +0100
Subject:    GAP on Mac

The new Mac version is essentially completed.  I will send you the date at
which it can be ftp'd.  Harry Lakser has done a fantastic job on the new
interface. The read me letter will contain all details.
N. S. Mendelsohn



From michel@dmi.ens.fr Tue Feb 23 11:06:00 1993
From:       michel@dmi.ens.fr "Jean Michel"
Date:       Tue, 23 Feb 93 11:06:00 +0100
Subject:    First impressions of 3.2

I have just installed 3.2 on my PC (a 66Mhz 486). The number of
gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the
improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude
that much of the improvement on the PC must be due to a better
C compiler. Impressive! (and congratulations!)

Also I like very much the facility offered by {} indexing, which
I timed as being 5 times faster than Sublist. However, I find
myself writing all the times things like:
l{[4..7]} or l{[3,5,9]}
could not a syntax like
l{4..7} or l{3,5,9} 
be accepted to mean the same?

Also, polynomials are great, but I have trouble using them. Maybe it is
just me or the documentation: I have a polynomial over the integers
which I know is a product of cyclotomic polynomials plus a constant.
I want to find out exactly what product and what constant.
As it is I cannot do that, because I did not find the routine to do
the Euclidean division of two polynomials.
I found a routine for the Gcd, but not for
the division. Did I miss something?

One last thing: I notices that 3+[] and []+3 are now both accepted and
return []. I hastily changed my function
   plus:=function(a,b)
	 if Length(a)=0 then return a;
	 elif Length(b)=0 then return b;
	 else return a+b;
	 fi;
	 end;
to calls of '+' again.
I say hastily because []+[] still does not work! I had to go back to
the old version for the case of equal-length vectors.
What's funny is that the error message has changed for that case:
it used to be 'Vectors: '+' incompatible types'
it is now:    '+ not defined for Lists'

Jean MICHEL, DMI, ENS



From borbor@divsun.unige.ch Tue Feb 23 11:38:39 1993
From:       borbor@divsun.unige.ch "Borcic Boris"
Date:       Tue, 23 Feb 93 11:38:39 +0100
Subject:    GAP for MAC, new version ?

I think I recall a new version of GAP for the Macintosh
was promised maybe mid-december for maybe mid-january
by the authors of the original port.

Is it still in the works ?

Regards,

Boris Borcic
---
(12^2-55)^2-12^2*55-1=0



From fceller@bert.math.rwth-aachen.de Tue Feb 23 13:32:47 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 23 Feb 93 13:32:47 +0100
Subject:    Re: Re: GAP on super/parallel computers

Dawn Endico writes:
>Archives?!?  That reminds me that I've been meaning to ask whether
>anyone has gap-forum archives available on a gohper server.  FTP?

we do not provide a gopher service, but the old mails to gap-forum
can be found on "samson.math.rwth-aachen.de" in "tmp":

-r--r--r--  1 ftp      system      96688 Sep 21 17:39 forum92b.txt
-r--r--r--  1 ftp      system     112618 Oct  8 09:42 forum92c.txt
-r--r--r--  1 ftp      system     129896 Jan 26 17:27 forum92d.txt


best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Tue Feb 23 13:55:41 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 23 Feb 93 13:55:41 +0100
Subject:    Re: garbage collection

>I've been using gap with the -g option, so I have some idea
>what's going on during long computations.  Does anyone know
>what the performance penalty is ?

there is no performance penalty, except for the time used to actually
print the message on the screen.

best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:04:06 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 23 Feb 93 14:04:06 +0100
Subject:    Re: First impressions of 3.2

>I have just installed 3.2 on my PC (a 66Mhz 486). The number of
>gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the
>improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude
>that much of the improvement on the PC must be due to a better
>C compiler. Impressive! (and congratulations!)

It is more or less the same compiler, the performance loss in GAP 3.1
is due to the *very* costly routine that checks for <ctrl-c> and
<alt-c>, because the program has to switch from 32bit-mode to
msdos-mode.

You can now set the interrupt check frequency using the "-z" flag.
The default value is 20.

best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:32:26 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 23 Feb 93 14:32:26 +0100
Subject:    Re: First impressions of 3.2

>I found a routine for the Gcd, but not for
>the division. Did I miss something?

no, you are not missing anything, the routine 'EuclideanQuotient' was not
ready before the final deadline.

The following routine should work for polynomials over fields:

-----------------------------------------------------------------------------
EuclideanQuotient := function ( f, g )
    local   m,  n,  i,  k,  c,  q,  R,  val;

    # <f> and <g> must have the same field
    if f.baseRing <> g.baseRing  then
        Error( "<f> and <g> must have the same base ring" );
    fi;

    # and they must be ordinary polynomials
    if f.valuation < 0  then
        Error( "<f> must not be a laurent polynomial" );
    fi;
    if g.valuation < 0  then
        Error( "<g> must not be a laurent polynomial" );
    fi;
    R := f.baseRing;

    # if <g> is zero signal an error
    if 0 = Length(g.coefficients)  then
        Error( "<g> must not be zero" );
    fi;

    # if <f> is zero return it
    if 0 = Length(f.coefficients)  then
        return f;
    fi;

    # remove the valuation of <f> and <g>
    f := ShiftedCoeffs( f.coefficients,  f.valuation );
    g := ShiftedCoeffs( g.coefficients,  g.valuation );

    # Try to divide <f> by <g>
    q := [];
    n := Length(g);
    m := Length(f) - n;
    for i  in [ 0 .. m ]  do
        c := f[m-i+n] / g[n];
        for k  in [ 1 .. n ]  do
            f[m-i+k] := f[m-i+k] - c * g[k];
        od;
        q[m-i+1] := c;
    od;

    # return the polynomial
    return Polynomial( R, q, 0 );

end;
-----------------------------------------------------------------------------

best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:39:28 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 23 Feb 93 14:39:28 +0100
Subject:    Re: First impressions of 3.2

>What's funny is that the error message has changed for that case:
>it used to be 'Vectors: '+' incompatible types'
>it is now:    '+ not defined for Lists'

This is because the internal mechanisms for accessing lists, plain
list, vectors, sets and strings have changed (in order to unify them).

best wishes
  Frank Celler



From sam@ernie.math.rwth-aachen.de Tue Feb 23 19:07:27 1993
From:       sam@ernie.math.rwth-aachen.de "Thomas Breuer"
Date:       Tue, 23 Feb 93 19:07:27 +0100
Subject:    

Dear Mrs. and Mr. Forum,
in his latest message Steve Linton writes

> Is there a comprehensive list of changes from 3.1 to 3.2?

Unfortunately such a list does not exist.  But I try to give an overview
(without guarantee of completeness).

There are five different kinds of changes.

1) New features in the GAP language.
2) New files in the GAP library, a result of new structures in GAP.
3) New functions for structures that already existed in GAP-3.1.
4) New data.
5) New behaviour of objects that already existed in GAP-3.1.

ad 1): These are the five extensions pointed out in the announcement, namely
         the access to sublists via curly brackets '{' and '}',
         the existence of permutations acting on points larger than 65535,
         the generalization of ranges,
         the generalization of matrices, and
         the representation of strings equal to lists.

       Additionally, GAP-3.2 is a little bit more exact in detecting global
       variables in user-defined functions.

ad 2): The following files are new in GAP-3.2.

       agctbl.g:    AgGroup specific parts of the Dixon-Schneider algorithm
       cdaggrp.g:   functions for calculating the degrees of the irreducible
                    characters of a solvable group
       chevgrp.g:   information about Chevalley-groups (used in "recsl.g")
       ctgapmoc.g:  functions used for conversion of GAP tables to MOC format
       ctlattic.g:  functions mainly dealing with lattices in the context of
                    character tables
       fpsgpres.g:  functions that compute presentations of subgroups of
                    finitely presented groups
       fptietze.g:  functions that compute presentations of subgroups of
                    finitely presented groups
       grpctbl.g:   the Dixon-Schneider Algorithm for computing character
                    tables of groups
       permag.g:    functions that calculate composition series for solvable
                    permutation groups and convert such groups into ag groups
       permcose.g:  functions to  work  with  cosets  of subgroups  in
                    permutation groups
       permcser.g:  functions to compute composition series for permutation
                    groups and related stuff
       permctbl.g:  permutation group specific parts of the Dixon-Schneider
                    algorithm
       permprod.g:  functions for group products and group constructions
       polyfin.g:   functions for polynomials over finite fields
       polyfld.g:   functions for polynomials over fields
       polynom.g:   functions that are dispatchers for polynomial functions,
                    and the polynomial arithmetic
       polyrat.g:   functions for polynomials over finite fields
       recsl.g:     function which help to recognize SL(q,n)
       tom.g:       functions dealing with Tables Of Marks

       Also new are the share library packages in directories 'anupq', 'nq',
       and 'weyl', as described in the announcement.

ad 3): The following functions are new (Note that additionally some NAMES
       of functions meanwhile have changed, e.g., all functions defined in
       file 'pq.g'.).

       AGDoubleCosets, AddDecMats, AscendingChain, BasicSetBrauerTree,
       BetaSet, BrauerTree, CalcDoubleCosets, CanonicalCosetElement,
       CanonicalRightTransversal, CharacteristicPolynomial,
       CycleStructurePerm, DifferenceBlist, ElementVector, Exponent,
       Extension, FactorAgSubgroup, FieldMatrices, FieldMatricesOps,
       FiniteFieldMatrices, FiniteFieldMatricesOps, GenRelOrdersAgGroup,
       IntegralizedMat, IntersectionBlist, IsIdentical, LeftCosetAgGroupOps,
       LinearIndependentColumns, MainEntryCCEAgGroup, MakeStabChainRandom,
       MaximalBlocks, MinMaxLatticeRelation, MinimalPolynomial,
       OnCanonicalCosetElements, PCore, PadicCoefficients, PermCharInfo,
       PermutationCharacter, PrintClassSubgroupLattice,
       PrintGroupSubgroupLattice, PrintMaxSubgroupLattice,
       PrintMinSubgroupLattice, Radical, RefinedChain,
       RelatorRepresentatives, RelsSortedByStartGen, RequirePackage,
       RightCosetMatGroupOps, Save, SetPrintLevel, SortCharTable,
       UnionBlist,

       (Some of them are self-explanatory, all can be looked up in the
       manual resp. online-help.)

ad 4): There is a library of 3-groups, as said in the announcement.

       Additionally there are functions computing classical (matrix) groups,
       namely 'GeneralLinearGroup', 'SpecialLinearGroup', 'SymplecticGroup',
       'GeneralUnitaryGroup', and 'SpecialUnitaryGroup'.

       The about 60 new tables in the character table library are mainly
       those of maximal subgroups of sporadic simple groups.  Also new is a
       component 'maxes' in the table record of tables of sporadic simple
       groups, a list containing the names of the tables their maximal
       subgroups; note that not yet all these tables are available in GAP.

ad 5): This is of course the most interesting kind of changes, since
       everything listed up here will probably cause trouble for someone
       who has written programs for GAP-3.1.

       First, some functions that were written in the GAP language in 3.1
       have been put into the kernel, like 'OnPoints'.  The different
       behaviour is mainly that such functions work much faster now, and
       in some cases errors are detected at an earlier stage.

       Next, some function names have changed, that is, the manual knows
       them under a new name; but we hope that GAP-3.2 allows you to
       access them also under the old name.

       The extensions of the language cause different behaviour of some
       functions; 'IsList' will return 'true' also for lists in GAP-3.2
       (which makes it difficult to distinguish empty list and empty string),
       and 'IsRange' returns 'true' for the more general type of ranges in
       GAP-3.2, which also may cause some strange results when using code
       written for GAP-3.1.

       The format of character tables in the library has changed.  This
       should not be of any interest for the user, except that some
       redundant data (like 'indicator' components ) is simply omitted in
       the GAP-3.2 library.

I hope this list is a little bit useful.  Sorry again that we have no
complete and official list of changes.  For the next release we should provide
this.

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



From felsch@samson.math.rwth-aachen.de Wed Feb 24 12:26:10 1993
From:       felsch@samson.math.rwth-aachen.de "Volkmar Felsch"
Date:       Wed, 24 Feb 93 12:26:10 +0100
Subject:    Re: Change List

Yesterday, Thomas Breuer has already given a first answer to Steve
Linton's question

> Is there a comprehensive list of changes from 3.1 to 3.2?

I would like to add to his list a few more remarks concerning changes
and extensions of functions described in the manual chapters "Groups",
"Table of Marks", "Finite Polycyclic Groups", and "Finitely Presented
Groups".


Chapter "Groups"
----------------

Facilities for computing and printing the subgroup lattice of a
given group have been added, and an explicit description of the
respective new functions

   Lattice
   PrintClassSubgroupLattice
   SetPrintLevel

has been added to the manual setcion.

The description of the TableOfMarks function has been removed from
the setcion and moved to an own chapter.


Chapter "Table of Marks"
------------------------

The function TableOfMarks to compute Burnside's table of marks of a
finite group has been changed and extended by several new functions
for handling such tables. The new chapter "Table of Marks" describes
all these functions:

   TableOfMarks
   Marks
   NrSubs
   WeightsTom
   MatTom
   TomMat
   DecomposedFixedPointVector
   TestTom
   DisplayTom
   NormalizerTom
   IntersectionsTom
   IsCyclicTom
   FusionCharTableTom
   PermCharsTom
   MoebiusTom
   CyclicExtensionsTom
   IdempotentsTom
   ClassTypesTom
   ClassNamesTom
   TomCyclic
   TomDihedral
   TomFrobenius


Chapter "Finite Polycyclic Groups"
----------------------------------

Since the release of version 3.1 some functions have been renamed or
replaced by global functions:

   pQuotient             -> PQuotient, PrimeQuotient
   pQpresentationSave    -> Save
   pQpresentationRestore -> PQp
   pQpresentationPrint   -> Print
   pQInit                -> InitPQp
   pQWeight              -> Weight
   NextClass             -> NextClassPQp
   pAbelianQuotient      -> FirstClassPQp
   DefiningGenerators    -> Factorization

They are now properly described in the GAP 3.2 manual release.


Chapter "Finitely presented group"
----------------------------------

This chapter has been extended by six sections which describe new
functions for handling group presentations. As GAP does never allow
to alter any presentation which is part of a group record, we have
introduced so called "presentation records" as a new type of GAP
objects which are permitted to be changed. The functions

   PresentationFpGroup
   FpGroupPresentation
   TzPrintStatus
   TzPrintGenerators
   TzPrintRelators
   TzPrintPresentation
   TzPrint
   TzPrintLengths
   TzPrintPairs
   TzPrintOptions
   Save
   AddGenerator
   AddRelator
   RemoveRelator

allow to create, administrate, print, or alter such pressentation
records. In particular, Tietze transformations can be applied to
them via the functions

   SimplifiedFpGroup
   SimplifyPresentation
   TzGo
   TzGoGo
   TzEliminate
   TzSearch
   TzSearchEqual
   TzFindCyclicJoins
   TzSubstitute
   TzSubstituteCyclicJoins

Moreover, we offer new functions

   PresentationSubgroup
   PresentationSubgroupMtc
   PresentationSubgroupRrs
   PresentationNormalClosure
   PresentationNormalClosureRrs
   DecodeTree

for computing a presentation of a subgroup of a finitely presented
group using the so called Modified Todd-Coxeter method or the
Reduced Reidemeister-Schreier algorithm.


I hope these remarks will be another help in figuring out at least
some features which are new in GAP 3.2 .

Volkmar Felsch



From michel@dmi.ens.fr Wed Feb 24 18:31:11 1993
From:       michel@dmi.ens.fr "Jean Michel"
Date:       Wed, 24 Feb 93 18:31:11 +0100
Subject:    ranges

The new ranges are an improvement, but...
I find the fact that <high>-<low> must be divisible (the error message
says divisable which is a misspelling) by <inc> to be slightly
annoying. I had in my code thinks like:
    [1..QuoInt(n+1,2)]*2-1
to specify the odd integers smaller than n, and
    [1..QuoInt(n,2)]*2
to specify the even integers less than n. I hoped to be able to rewrite
these as
    [1,3..n] and [2,4..n]
but the first one works only for n odd and the second for n even!
One has to use
    [1,3..n-1+(n mod 2)] and  [2,4..n-(n mod 2)]
which is less pleasant and efficient.

What is the rationale for the restriction?



From kaskel@math.berkeley.edu Fri Feb 26 17:42:28 1993
From:       kaskel@math.berkeley.edu "Bruce Kaskel"
Date:       Fri, 26 Feb 93 17:42:28 +0100
Subject:    

Could someone possibly tell me what I am doing wrong here? This is my
first time using GAP and I can't see why this doesn't work.
Why does it hit this error?


Thank you in advance for any help given. 
You can e-mail to me at kaskel@math.berkeley.edu
---------------------------------------------------------------------------

gap> s4:=SymmetricGroup4 (4);
Group( (1,4), (2,4), (3,4) )
gap> cc:=ConjugacyClassesSubgroups(s4);
[ ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [  ] ) ), ConjugacyClassSubgroups( Group( (1,4), 
    (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (2,3,4) ] ) ), ConjugacyClassSubgroups( Group( 
    (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), 
    [ (1,2)(3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), 
    (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4), (1,2) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (2,3,4), (3,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3)(2,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3,2,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (3,4), (1,2)(3,4), (1,3)(2,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
    (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3)(2,4), (2,3,4) ] ) ), 
  ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Group( (1,4), (2,4), 
    (3,4) ) ) ]
gap> cc2:=cc[2];
ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( 
(1,4), (2,4), (3,4) ), [ (3,4) ] ) )
gap> r:=Representative(cc2);
Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4) ] )
gap> g:=Group(r);
Group( (3,4) )
gap> 2syl:=SylowSubgroup(g,2);
Error, Record: element 'orbit' must have an assigned value at
while Length( G.orbit ) mod p <> 0 ... in
G.operations.SylowSubgroup( G, p ) called from
SylowSubgroup( g, 2 ) called from
main loop
brk> 

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



From hwb@machnix.mathematik.uni-stuttgart.de Fri Feb 26 20:53:03 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Fri, 26 Feb 93 20:53:03 +0100
Subject:    porting GAP to OS/2 2.0 with emx

Hello!
I have just acquired GAP and have no experience with it. Even before
trying it at all I thought it might be nice to have it working on my
PC under OS/2 2.0.

Has anybody ported GAP to OS/2 2.0?

Let me tell you what I did so far:

I compiled GAP 3.2 using the emx0.8f port of gcc. Since emx provides a
very unix-like environment, I used sysunix.c and SYS_IS_USG. After
changing only about 4 lines, GAP compiled without problems and is now
working under OS/2 2.0, including the command line editor. Since emx
produces bound executables for DOS and OS/2 2.0, I am wondering why
the DOS port of GAP was done using DJ Delorie's gcc / DOS extender and
not emx.

Some work remains to be done, I admit. At least the command line
editing should be changed so that the cursor keys can be used. Before
spending any time on this I'd like some feedback: Has anybody already
done this?

To the GAP developers: Wouldn't it be much nicer to have a single
executable of GAP for DOS and OS/2?


Regards,
Harald



P.S.: private Mail an mich kann man natuerlich auch auf Deutsch
schreiben.

--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From martin@bert.math.rwth-aachen.de Mon Mar  1 11:30:30 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 11:30:30 +0100
Subject:    Re: GAP on super/parallel computers

In his e-mail message of 1993/02/17, Frederick Ford wrote
    I have an opportunity to get some "free" time on either a super  
    computer or a parallel computer.

    The super computer options are:

                      OS              C compiler
      IBM ES-9000     AIX/370         AIX/370 C compiler
      IBM RS-6000     AIX             AIX XL C compiler/6000
      Cray-YMP        UNICOS          Cray standard C compiler

The easiest option is the RS/6000 (usually those machines are considered
workstations or servers, not super computers).  Porting GAP to the
ES-9000 (under AIX) should also be reasonably simple.  I would expect a
ES-9000 to run GAP about a factor of two faster than a large RS/6000.
Which machine is better depends on the number of other users on each
system, the amount of memory installed, etc.

GAP does *not* run on Crays.  The reason is that GAP makes certain
assumptions about the format of pointers that aren't valid on Crays.  It
could probably be made to work, but (as far as I know) nobody is
currently trying.  It wouldn't make much sense because GAP could not make
use of the special hardware (vector units, etc.) that make Crays so fast
for numerical code.  So GAP on a Cray probably wouldn't run significantly
faster than on a fast UNIX workstation (maybe twice or three times as
fast).

He continues:

    The parallel computer is a Connection Machine (massively parallel I'm  
    told). The OS is System V, BSD 4.3 compatible. I don't have any  
    details on the C compiler version, but it's whatever Thinking  
    Machines is distributing as their "standard" C compiler.

GAP contains no explicit parallel constructs, and I doubt that there are
many place where the compiler could automatically find parallelizable
code.  I don't think you should try.

Martin.

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



From martin@bert.math.rwth-aachen.de Mon Mar  1 11:57:14 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 11:57:14 +0100
Subject:    Re: 

In his e-mail message of 1993/02/26, Bruce Kaskel writes:
    Could someone possibly tell me what I am doing wrong here?

    gap> s4 := SymmmetricGroup( 4 );;
    gap> cc := ConjugacyClassesSubgroups( s4 );;
    gap> cc2 := cc[2];;
    gap> r := Representative( cc2 );;
    gap> g := Group( r );
    Group( (3,4) )
    gap> 2syl := SylowSubgroup( g, 2 );
    Error, Record: element 'orbit' must have an assigned value at
    ...

This is a bug in GAP 3.1 (patchlevel 0).  It is fixed in the first
upgrade to V3R1P1 and in GAP 3.2.  The problem was that
'PermGroupOps.SylowSubgroup' assumed that once the size of a permutation
group is known (and it is known for 'g', since it was known for 'r'),
also a stabilizer chain is known (but 'g' has no stabilizer chain,
because this is not copied by 'Group').

Martin.

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



From sl25@cus.cam.ac.uk Mon Mar  1 13:39:49 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Mon, 1 Mar 93 13:39:49 +0100
Subject:    Re: porting GAP to OS/2 2.0 with emx 

Harald Boegeholz writes:
> 
> I have just acquired GAP and have no experience with it. Even before
> trying it at all I thought it might be nice to have it working on my
> PC under OS/2 2.0.
> 
> Has anybody ported GAP to OS/2 2.0?

Not as far as I know.

> 
> Let me tell you what I did so far:
> 
> I compiled GAP 3.2 using the emx0.8f port of gcc. Since emx provides a
> very unix-like environment, I used sysunix.c and SYS_IS_USG. After
> changing only about 4 lines, GAP compiled without problems and is now
> working under OS/2 2.0, including the command line editor. Since emx
> produces bound executables for DOS and OS/2 2.0, I am wondering why
> the DOS port of GAP was done using DJ Delorie's gcc / DOS extender and
> not emx.

Basically because I didn't have an OS/2 system. 

How do the emx produced DOS executables behave? What expanded
memory/swapping protocols will they use? How fast are they? Apart
from the kbhit() problem identified a few weeks ago, the DJGPP
executables seem to work pretty well in a variety of environments.

> 
> Some work remains to be done, I admit. At least the command line
> editing should be changed so that the cursor keys can be used. Before
> spending any time on this I'd like some feedback: Has anybody already
> done this?

Again, not as far as I know. The DJGPP port (sysdos.c or whatever
it`s called now) uses various arrow keys and so on, but I doubnt
that you could use the same code.
> 
> To the GAP developers: Wouldn't it be much nicer to have a single
> executable of GAP for DOS and OS/2?
> 
I would certainly think so, but there seem to be far more DOS than
OS/2 users, so DOS performance is an important consideration.

		Steve Linton



From hwb@machnix.mathematik.uni-stuttgart.de Mon Mar  1 15:33:49 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Mon, 1 Mar 93 15:33:49 +0100
Subject:    porting GAP to OS/2 2.0 with emx 

   Date: Mon, 1 Mar 93 13:42:12 +0100
   From: Steve Linton <sl25@cus.cam.ac.uk>
   To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
   Subject: Re: porting GAP to OS/2 2.0 with emx 

   Harald Boegeholz writes:
   > 
   > I have just acquired GAP and have no experience with it. Even before
   > trying it at all I thought it might be nice to have it working on my
   > PC under OS/2 2.0.
   > 
   > Has anybody ported GAP to OS/2 2.0?

   Not as far as I know.

   > 
   > Let me tell you what I did so far:
[...]
   How do the emx produced DOS executables behave? What expanded
   memory/swapping protocols will they use? How fast are they? Apart
   from the kbhit() problem identified a few weeks ago, the DJGPP
   executables seem to work pretty well in a variety of environments.

Sinc I just joined the GAP-forum, I don't know about "the
kbhit()-problem". Could you tell me what that was? 

As for the DOS performance of emx: I haven't made any speed
measurements yet, but I can do that sometime. emx does not support
DPMI, but does support VCPI or XMS. It can also coexist with VDISK.SYS
3.3 and later. emx uses all available memory, whether conventional,
extended or expanded memory. But it does not use extended AND expanded
memory at the same time. emx will swap to disk if there isn't enough
real memory.

On the whole I think that it is comparable to DJGPP/GO32, with the
additional benefit that it produces executables that work under OS/2
2.0 as well. I cannot imagine why it should be slower, but I will try
that soon. 
   > 
   > Some work remains to be done, I admit. At least the command line
   > editing should be changed so that the cursor keys can be used. Before
   > spending any time on this I'd like some feedback: Has anybody already
   > done this?

   Again, not as far as I know. The DJGPP port (sysdos.c or whatever
   it`s called now) uses various arrow keys and so on, but I doubnt
   that you could use the same code.
If nobody else is doing it, I will look into that as my spare time
allows.


mfg
hwb
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From sl25@cus.cam.ac.uk Mon Mar  1 17:23:22 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Mon, 1 Mar 93 17:23:22 +0100
Subject:    Re: porting GAP to OS/2 2.0 with emx 

> Sinc I just joined the GAP-forum, I don't know about "the
> kbhit()-problem". Could you tell me what that was? 

The DJGPP version was spending a rather large proportion of
its time switching back into 8086 mode to check if a key had
been pressed (in case it was an interrupt key). By reducing
the frequency of such tests (see the GAP-3.2 sysdos.c) a
substantial performance improvement was acheived.

		Steve



From martin@bert.math.rwth-aachen.de Mon Mar  1 20:35:40 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 20:35:40 +0100
Subject:    Re: First impressions of 3.2

In his e-mail message of 1993/02/23, Jean Michel writes
    I have just installed 3.2 on my PC (a 66Mhz 486). The number of
    gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the
    improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude
    that much of the improvement on the PC must be due to a better
    C compiler. Impressive! (and congratulations!)

As Frank already noted, the main reason for the performance jump is that
GAP now checks for user interrupt less frequently.

He continues:

    Also I like very much the facility offered by {} indexing, which
    I timed as being 5 times faster than Sublist. However, I find
    myself writing all the times things like:
    l{[4..7]} or l{[3,5,9]}
    could not a syntax like
    l{4..7} or l{3,5,9} 
    be accepted to mean the same?

We are giving some thoughts to extend the concept of lists to the more
general concept of a table.  In a table the index could be any object,
not just a positive integer.  So you could, for example, index into a
table with permutations, lists, etc.  At one time the syntax I had in
mind for sublist extraction made it neccessary to always have a list
expression in the sublist construct '<list>{<poss>}', so that GAP could
distinguish between extracting a single element at an index given by a
list and extracting a whole sublist at indices given by a list.  The
current syntax cannot lead to such a confusion, so 'l{4..7}' or
'l{3,5,9}' could -- and probably will -- be accepted in a future version.

He continues:

    One last thing: I notices that 3+[] and []+3 are now both accepted and
    return [].

Yes.  But you probably should not use this.  Or at least if you use this
be aware that further rewrites of the list packages may remove this
funcionality again (though this is not very likely).  I will write more
on the subject of empty lists in a seperate e-mail message.

Martin.

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



From martin@bert.math.rwth-aachen.de Mon Mar  1 20:55:05 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 20:55:05 +0100
Subject:    Re: integer vector mod integer

In his e-mail message of 1993/02/16, Werner Nickel writes
    in writing some routines to deal with integer vectors modulo a positive
    integer I discovered that the operation   vec mod scalar   in GAP 3.1 is
    not possible:

    gap> [1,2,3,4,5,6] mod 2;
    Error, operations: remainder of list and integer is not defined

    ...

    It would be useful to have the operation   vec mod scaler   available
    for those cases where taking the remainder makes sense. For a similar
    reason the operation   vec mod vec   for integer vectors is useful.
    The operation would be defined componentwise. In this way one could
    easily do computations in finite abelian groups. For example, adding
    two vectors in the group C_2 x C_4 x C_12 could be done as follows:

    gap> ([1,2,3] + [4,5,6]) mod [2,4,12];
    [1,3,9]

I never implemented this, because it didn't appear very usefull to me.
But your last example is very nice (reminds me of the first program I
ever worked on at the Lehrstuhl D ;-).  As a matter of fact the manual
for GAP 3.1 contains one example where the ability to compute '<vec> mod
<int>' is used (of course this example never actually worked).

Expect this to come soon.

Martin.

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



From martin@bert.math.rwth-aachen.de Mon Mar  1 21:30:08 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 21:30:08 +0100
Subject:    Re: ranges

In his e-mail message of 1993/02/24, Jean Michel writes
    The new ranges are an improvement, but...
    I find the fact that <high>-<low> must be divisible (the error message
    says divisable which is a misspelling) by <inc> to be slightly
    annoying. I had in my code thinks like:
        [1..QuoInt(n+1,2)]*2-1
    to specify the odd integers smaller than n, and
        [1..QuoInt(n,2)]*2
    to specify the even integers less than n. I hoped to be able to rewrite
    these as
        [1,3..n] and [2,4..n]
    but the first one works only for n odd and the second for n even!
    One has to use
        [1,3..n-1+(n mod 2)] and  [2,4..n-(n mod 2)]
    which is less pleasant and efficient.

    What is the rationale for the restriction?

The rationale is that a construct such as

    for i in [1,3..n] do ...

has a visual clue that <n> is in fact a member of the range, and that it
will be the last value of <i>.  That is a programmer might
(unconsciously) follow that <n> is in the range (in the membership
sense), because it is in the range literal (in a textual sense).  But
this visual clue could be misleading if GAP would be silently rounding,
because then in the above example <n> would be a member of the range only
if it is odd.

I have to admit that this is a somewhat weak argument.  If one would
apply it consequently, '[<i>,<j>..<k>]' would also have to generate an
error if '<k> < <j>', because in this case <j> is not in the range, even
though it is in the range literal.

Actually, I don't really care one way or the other.  If other users would
also prefer silent rounding, I am quite willing to change the definition
and the code accordingly (which is not a big deal).

Martin.

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



From martin@bert.math.rwth-aachen.de Mon Mar  1 21:57:07 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 1 Mar 93 21:57:07 +0100
Subject:    Re: porting GAP to OS/2 2.0 with emx 

In his e-mail message of 1993/03/01, Harald Boegeholz writes:
    Sinc I just joined the GAP-forum, I don't know about "the
    kbhit()-problem". Could you tell me what that was? 

In the DOS port the function 'kbhit()' was used by GAP to poll whether
the user had entered <ctr>-'C'.  Since this meant switching from
protected mode to real mode and back, it took rather long, and since it
was called quite frequently, it reduced GAP's performance significantly.

How does the 'emx' version test whether the user entered <ctr>-'C'?
Since you write that 'emx' simulates a UNIX environment, does the
extender catch the keyboard interrupt and deliver it to GAP as a signal,
i.e., is 'SyAnsIntr' called if the user enters <ctr>-'C'?

I suggest that you upload your executable to

    'samson.math.rwth-aachen.de:pub/tmp'

once you feel it is ready.  Then we can all experiment whether it runs
not at all, slower, as fast, or faster as the current DOS version.  Write
me and I will set the permissions of 'pub/tmp' accordingly.

Martin.

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



From jcbhrb@cerf.net Tue Mar  2 23:48:08 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Tue, 2 Mar 93 23:48:08 +0100
Subject:    Trouble compiling gap under DOS

gap-forum@samson.math.rwth-aachen.de
I am having trouble compiling the source code of gap3.2 under DOS.
I am using djgpp2.22 and NDMAKE4.5 . I was hoping things would be
as simple as typing make "ibmpc-msdos-djgpp" in the src directory;
but no such luck. Any suggestions?

Jacob Hirbawi
JcbHrb@CERF.net

PS. I did get the executable and it's working fine; I would just like
    to do the compilation myself as an excercise.

PPS. Apparently my e-mail last week did not go through beacuse of the
     disk space problem; unfortunately I didn't find that out until 
     after I deleted it. In it I just wanted to thank Thomas Breuer for his
     response to my question on the direct calculation of characters and a 
     report that gap3.2 correctly calculated the characters of the groups
     <2,3,3>,<2,3,4>, and <2,3,5> in a matter of minutes on a 50MHz 486;
     it took a little longer to do the same on an DEC 3100 Ultrix machine.



From kaup@ccucvx.unican.es Wed Mar  3 10:13:09 1993
From:       kaup@ccucvx.unican.es "Ansgar Kaup"
Date:       Wed, 3 Mar 93 10:13:09 +0100
Subject:    new test for GAP 3.2 or old test valid

I want to know if there is a new test like the file combinat.tst for the new 
GAP or is the old test valid for the new release, too. I installed GAP 3.2 in 
some NeXT-Stations and noticed, that the test obtains about a third part less
"GAP-Stones" together with GAP-3.2. The results of our SUN didn't change so far
Saludos,
             Ansgar



From martin@bert.math.rwth-aachen.de Wed Mar  3 10:23:41 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 3 Mar 93 10:23:41 +0100
Subject:    Re: new test for GAP 3.2 or old test valid

The old "combinat.tst" is still valid, after all "combinat.g" didn't
change.  Generally 3.2 gives slightly higher GAPstones than 3.1, but not
much.  The exception is of course the DOS version, where 3.2 is quite a
bit faster.

Martin.

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



From fceller@bert.math.rwth-aachen.de Wed Mar  3 11:15:57 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Wed, 3 Mar 93 11:15:57 +0100
Subject:    Re: new test for GAP 3.2 or old test valid

>some NeXT-Stations and noticed, that the test obtains about a third part less
On NeXT Station running NeXTSTEP 2.1:

marvin> bin/gap-3.2 -m 4m -g -b 
gap> ReadTest("tst/combinat.tst");
$Id: combinat.tst,v 3.2 1992/11/25 14:49:10 martin Exp $  18182 GAPstones

This  is slightly more than the reported 16484 GapStones for  GAP 3.1,
as expected.  Both executables were compiled with GCC 2.x.y.  However,
if you compile GAP using CC (which  is GCC  1.36) the performance will
drop.

best wishes
  Frank



From DARDANO@matna.na.infn.it Wed Mar  3 14:15:24 1993
From:       DARDANO@matna.na.infn.it "Ulderico Dardano"
Date:       Wed, 3 Mar 93 14:15:24 +0100
Subject:    Mac-user looks for GAP on Mac

Macintosh user(s) would be happy to run GAP on Macintosh.

Can someone help them?

Has someone ported GAP on Mac?

If yes, how can the application be got ?

I am a fresh subscriber  who will aprreciate any help!

				thank you,

----------------------------------------------
Ulderico Dardano
Dip. Matematica e Appl. RR. CaccioppoliS
Monte S. Angelo T, v. Cintia,  I-80126 Napoli - Italy
Tel: +39 81 675713 (direct)    Fax: +39 81 7662106
E-mail:  dardano@matna.na.infn.it
----------------------------------------------



From caranti@volterra.cineca.it Wed Mar  3 17:08:39 1993
From:       caranti@volterra.cineca.it "Andrea Caranti"
Date:       Wed, 3 Mar 93 17:08:39 +0100
Subject:    AgGroups

Dear gap-forum,
consider the following piece of GAP code:

ElAb := function (p)
local a, b, g;
a := AbstractGenerator("a"); b := AbstractGenerator("b");
g := rec(
   generators := [a, b],
   relators := [a^p, b^p]
);
return AgGroupFpGroup (g);
end;

Now I do

gap> g := ElAb (2);
gap> RecFields(g);
[ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs",
  "operations", "1", "2" ]

No relators are stored in  the  record.  GAP knows how to compute with
the group g, which is a Klein four-group as expected, so

gap> Comm(g.1, g.2);
IdAgWord

works, but why are relators not written in the record describing g?  I
know I can put the relators in explicitly by doing

ElAb := function (p)
local a, b, g, h;
a := AbstractGenerator("a"); b := AbstractGenerator("b");
g := rec(
   generators := [a, b],
   relators := [a^p, b^p, Comm(a, b)]
);
h := AgGroupFpGroup(g);
h.relators := g.relators;
return h;
end;

but this of course would not work  when making use  of the feature  of
omitting trivial commutator relators, as in the first version of ElAb.
So my question is: why exactly are relators not (completed and) copied
in these circumstances?

Thank you very much in advance, yours

A Caranti

---------------------------------------------------------------------
A Caranti                                 Tel ++39 461 881618
Dipartimento di Matematica                Fax ++39 461 881624
Universita' degli Studi di Trento
I-38050 Povo (Trento)                     caranti@volterra.cineca.it
Italia                                    (preferred email address. Also:)
                                          caranti@itnsp2.cineca.it
                                          caranti@itncisca.bitnet

                                          Tel ++39 461 916087 (home)



From fceller@bert.math.rwth-aachen.de Wed Mar  3 17:42:52 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Wed, 3 Mar 93 17:42:52 +0100
Subject:    Re: AgGroups

> No relators are stored in  the  record.  GAP knows how to compute with
> the group g, which is a Klein four-group as expected, so
>
> gap> Comm(g.1, g.2);
> IdAgWord
>
> works, but why are relators not written in the record describing g?  I
> know I can put the relators in explicitly by doing

Each ag word carries a pointer to a data structure <D> created by
'AgGroupFpGroup'.  The right hand sides of all power-commutator
relations are stored in this data structure <D>,  but in such a way that
they need less space for non-trivial entries than the relators in
abstract generators and no (extra) space for trivial entries.
Creating the presentation in abstract generators would require a vast
amount of space, 28 bytes for each trivial relator.

best wishes
  Frank

PS: To be precise: power-conjugates relations for single and tuple
collectors and power-commutator relations for combinatorial collectors
are stored in <D>.



From hwb@machnix.mathematik.uni-stuttgart.de Wed Mar  3 22:35:13 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Wed, 3 Mar 93 22:35:13 +0100
Subject:    Re: new test for GAP 3.2 or old test valid

   Date: Wed, 3 Mar 93 10:25:54 +0100
   From: martin@bert.math.rwth-aachen.de (  Martin Schoenert)
   Subject: Re: new test for GAP 3.2 or old test valid

   The old "combinat.tst" is still valid, after all "combinat.g" didn't
   change.  Generally 3.2 gives slightly higher GAPstones than 3.1, but not
   much.  The exception is of course the DOS version, where 3.2 is quite a
   bit faster.

Where can I get a current copy of "combinat.tst"? I didn't find it on
samson.math.rwth-aachen.de, but maybe I wasn't looking close enough. I
have a copy but it seems to be outdated.

Are there other tests commonly used to test GAP performance?


Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From dentzer@polyhymnia.iwr.uni-heidelberg.de Thu Mar  4 15:52:59 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Thu, 4 Mar 93 15:52:59 +0100
Subject:    Re: AgGroups

> 
> > No relators are stored in  the  record.  GAP knows how to compute with
> > the group g, which is a Klein four-group as expected, so
> >
> > gap> Comm(g.1, g.2);
> > IdAgWord
> >
> > works, but why are relators not written in the record describing g?  I
> > know I can put the relators in explicitly by doing
> 
> Each ag word carries a pointer to a data structure <D> created by
> 'AgGroupFpGroup'.  The right hand sides of all power-commutator
> relations are stored in this data structure <D>,  but in such a way that
> they need less space for non-trivial entries than the relators in
> abstract generators and no (extra) space for trivial entries.
> Creating the presentation in abstract generators would require a vast
> amount of space, 28 bytes for each trivial relator.
> 
> best wishes
>   Frank
> 
> PS: To be precise: power-conjugates relations for single and tuple
> collectors and power-commutator relations for combinatorial collectors
> are stored in <D>.
> 
> 
But how can I see the relations of an ag group G that I read in from
e.g. the library of solvable groups or the library of 2-groups?
I want to find out how the generators G.1, ... correspond to the ones
in a presentation of G I have in another list of solvable groups,
or to correspond them to another description of G as e.g.
a semidirect product, or some other extension.


Ralf Dentzer

P.S.	Is there a function to test for isomorphism between two
	ag groups? This would maybe solve my problem, but I
	did not find such a function. Moreover this functions
	should also provide an isomorphism mapping generators
	of one group to as short as possible expressions in
	the generators of the second group.

P.P.S 	What I am doing now is guessing the correspondance and
	verifying the relations I know, but this is rather
	tedious.



From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar  4 16:14:06 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Thu, 4 Mar 93 16:14:06 +0100
Subject:    how do I run combinat.tst?

Hello!
I was just trying to run combinat.tst. On my machine (RS/6000 under
AIX 3.2) it fails to compute the number of GAPstones:

gap> Read("combinat.tst");
Error, Variable: 'time' must have a value
combinat  3.1   1992/04/29  gap> 

What am I doing wrong? Is there a later version of combinat.tst?


Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From ahulpke@bert.math.rwth-aachen.de Thu Mar  4 16:21:41 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Thu, 4 Mar 93 16:21:41 +0100
Subject:    Re: AgGroups

Dear GAP-Forum,
Ralf Dentzer asked, on how to obtain the presentation back from an AgGroup.

The command FpGroup will create a finitely presented group from an AgGroup.
The result has an entry .relators, that contains the relators of the
underlying Ag presentation. (The routine basically recomputes the
presentation by decomposing products and powers in the CGS).

  Alexander 



From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar  4 17:23:31 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Thu, 4 Mar 93 17:23:31 +0100
Subject:    A port of GAP to OS/2 2.0 and DOS

Hello!
I have started porting GAP 3.2 to emx, a free software development
system for OS/2 2.0 and DOS. I mainly did this because I wanted an
OS/2 version of GAP, but the resulting executable should run under
DOS, too.

This is my first try at porting GAP, and I have spent only very little
time on it. But if you need an OS/2 version or if you are curious
about another DOS version, give it a try!

I put the executable on

ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapemx.zip

Please read the enclosed documentation.


Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar  4 17:30:28 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Thu, 4 Mar 93 17:30:28 +0100
Subject:    how do I run combinat.tst?

Sorry for the stupid question:
>   I was just trying to run combinat.tst. On my machine (RS/6000 under
>   AIX 3.2) it fails to compute the number of GAPstones:

>   gap> Read("combinat.tst");
>   Error, Variable: 'time' must have a value
>   combinat  3.1   1992/04/29  gap> 

>   What am I doing wrong? Is there a later version of combinat.tst?


I have been told that I should have used ReadTest to read the test.
Stupid me!


Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From obrien@pell.anu.edu.au Thu Mar  4 23:35:30 1993
From:       obrien@pell.anu.edu.au "Eamonn O'Brien"
Date:       Thu, 4 Mar 93 23:35:30 +0100
Subject:    Re: AgGroups

Ralf Dentzer asks

> But how can I see the relations of an ag group G that I read in from
> e.g. the library of solvable groups or the library of 2-groups?

For groups in the 2-group or 3-group library, you access 
the field G.abstractRelators described on p. 571 of the manual 

gap> G := TwoGroup (32, 5);
Group( a1, a2, a3, a4, a5 )
gap> RecFields (G);
[ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs", 
  "operations", "1", "2", "3", "4", "5", "rank", "pclass", 
  "abstractGenerators", "abstractRelators" ]
gap> G.abstractRelators;
[ a1^2*a4^-1, a2^2, a2^-1*a1^-1*a2*a1*a3^-1, a3^2, a3^-1*a1^-1*a3*a1, 
  a3^-1*a2^-1*a3*a2, a4^2*a5^-1, a4^-1*a1^-1*a4*a1, a4^-1*a2^-1*a4*a2, 
  a4^-1*a3^-1*a4*a3, a5^2, a5^-1*a1^-1*a5*a1, a5^-1*a2^-1*a5*a2, 
  a5^-1*a3^-1*a5*a3, a5^-1*a4^-1*a5*a4 ]
gap>

He also asks
>P.S.	Is there a function to test for isomorphism between two
>	ag groups? This would maybe solve my problem, but I

I have implemented an algorithm which in a fair number of cases
allows one to decide whether two given p-groups are isomorphic.
The ANU p-Quotient Program provides access to this implementation.
Part of that program is already accessible as a package in GAP 3.2.
See Chapter 49 of the manual.

The isomorphism testing facility is not yet accessible
within GAP -- it should be available within a few months --
however, it is part of the stand-alone program. 
Any interested user should communicate *directly*
with me on this topic. 

++++++++++++++++++++++++++++++++++++++++++++++
Eamonn O'Brien
++++++++++++++++++++++++++++++++++++++++++++++
School of Mathematical Sciences
Australian National University

e-mail obrien@pell.anu.edu.au
++++++++++++++++++++++++++++++++++++++++++++++



From martin@bert.math.rwth-aachen.de Fri Mar  5 10:04:29 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Fri, 5 Mar 93 10:04:29 +0100
Subject:    Re: Re: new test for GAP 3.2 or old test valid

'combinat.tst' is in an old message to the GAP forum, which is archived
in the file 'ftp@samson.math.rwth-aachen.de:tmp/forum92d.txt'.  This is
version 3.1, which is still valid (except for the format of the output it
hasn't changed since April 92).

Currently there are no other tests, but we plan to add many more test
files.  Eventually we hope to cover every function in GAP with those test
files.

Martin.

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



From fceller@bert.math.rwth-aachen.de Fri Mar  5 14:54:26 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Fri, 5 Mar 93 14:54:26 +0100
Subject:    Re: Re: AgGroups

> Is there a function to test for isomorphism between two
> ag groups? This would maybe solve my problem, but I
> did not find such a function. Moreover this functions
> should also provide an isomorphism mapping generators
> of one group to as short as possible expressions in
> the generators of the second group.

How "big" are the ag groups you are interested in (composition length,
size of commutator factor group)?  There is a way to use 'Complements'
to find isomorphisms between ag groups, but this will only work if the
groups are not too big.

best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Fri Mar  5 15:02:46 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Fri, 5 Mar 93 15:02:46 +0100
Subject:    Re: Re: AgGroups

> The command FpGroup will create a finitely presented group from an AgGroup.
> The result has an entry .relators, that contains the relators of the
> underlying Ag presentation. (The routine basically recomputes the
> presentation by decomposing products and powers in the CGS).

If the ag group <G> is a parent with canonical generating system (this
is the case if you are using 'AgGroupFpGroup') then 'FpGroup(<G>)'
will construct the power-commutator presentation without collection.
So, "recomputes" is slightly misleading in this case.

best wishes
  Frank Celler



From fceller@bert.math.rwth-aachen.de Fri Mar  5 15:10:42 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Fri, 5 Mar 93 15:10:42 +0100
Subject:    Re: A port of GAP to OS/2 2.0 and DOS

> This is my first try at porting GAP, and I have spent only very little
> time on it. But if you need an OS/2 version or if you are curious
> about another DOS version, give it a try!

I have never used OS/2, so this might be a stupid question: Is it
possible to run a fairly large GAP (say 16 mbyte job) as background
process and to do some editing in the foreground on a PC 486/33Mhz
with 8 mbyte of RAM under OS/2?  Or is the swapping/paging to
annoying?


best wishes
  Frank Celler



From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar  5 16:24:36 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Fri, 5 Mar 93 16:24:36 +0100
Subject:    Re: Re: AgGroups

Many thanks to all who answered my questions!
The groups I am interested in are not very big, at most some hundred
elements, but can be rather complicated in structure.
My first problem is to recognize some groups from the literature or other
computations in the complete lists of (small) solvable groups (or
p-groups) contained in GAP, so that I get a complete overview of
the possibilities. Some of the groups are given by relations, some
as permutation groups and some as semidirect products or otherwise.

The second problem is to recognize subgoups and/or factor groups of
(solvable) groups in the given lists or to test isomorphism with
other subgroups/factor groups. Especially the isomorphism test
between subgroups should happen automatically (the groups involved
in this are very small!)

A further problem I am faced with is the computation of the
ConjugacyClassesSubgroups(G). I didn't try this with GAP 3.2 yet,
but for some groups of order 256 it took several hours with 3.1.
Did these routines improve? What I am really interested in are
the normal subgroups of G; is there a simpler way to compute them?
(Abelian groups and groups of nilpotency class 2 can be excluded.)

I intended to wait with further postings until I had taken a closer look
at GAP 3.2. But as some people showed their interest in these problems
I am now taking the easy way and ask the specialists for their
proposals.

Greetings,
	Ralf Dentzer

dentzer@kalliope.iwr.uni-heidelberg.de



From ahulpke@bert.math.rwth-aachen.de Fri Mar  5 16:50:54 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Fri, 5 Mar 93 16:50:54 +0100
Subject:    Re: Re: Re: AgGroups

Dear GAP-Forum,
In his message, Ralf Dentzer asked:

> A further problem I am faced with is the computation of the
> ConjugacyClassesSubgroups(G). I didn't try this with GAP 3.2 yet,
> but for some groups of order 256 it took several hours with 3.1.
> Did these routines improve? What I am really interested in are
> the normal subgroups of G; is there a simpler way to compute them?

ConjugacyClassesSubgroups can be *very* hard (especially for p-Groups),
since so many subgroups do exist. There also is a command 'NormalSubgroups',
which will only compute the normal subgroups (as closures of conjugacy
classes). In case the group still has lots of normal subgroups, one might also
consider computing the character table, and deriving the normal subgroups
from it.

     Alexander



From hwb@machnix.mathematik.uni-stuttgart.de Fri Mar  5 17:04:26 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Fri, 5 Mar 93 17:04:26 +0100
Subject:    A port of GAP to OS/2 2.0 and DOS

   Date: Fri, 5 Mar 93 15:13:31 +0100
   Comment: GAP Forum
   Originator: gap-forum@samson.math.rwth-aachen.de
   Reply-To: <gap-forum@samson.math.rwth-aachen.de>
   Sender: gap-forum@samson.math.rwth-aachen.de
   Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
   From: fceller@bert.math.rwth-aachen.de ( Frank Celler)
   To: Multiple recipients of list <gap-forum@samson.math.rwth-aachen.de>
   Subject: Re: A port of GAP to OS/2 2.0 and DOS

   > This is my first try at porting GAP, and I have spent only very little
   > time on it. But if you need an OS/2 version or if you are curious
   > about another DOS version, give it a try!

   I have never used OS/2, so this might be a stupid question: Is it
   possible to run a fairly large GAP (say 16 mbyte job) as background
   process and to do some editing in the foreground on a PC 486/33Mhz
   with 8 mbyte of RAM under OS/2?  Or is the swapping/paging to
   annoying?

I would consider 8 MByte of RAM the absolute minimum for OS/2 2.0,
even without GAP. With a 16MB GAP job in the background, I think
nothing would be moving at all, i.e., terrible swapping.

I have 13 MBytes of RAM, and after booting OS/2 and loading a little
screen saver I have about 4 MB free. So OS/2 uses at least 8 MB of RAM
for itself. Your 16 MB GAP job should run ok in 16 MBytes of memory,
I'd think.


Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From werner@pell.anu.edu.au Mon Mar  8 01:07:49 1993
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Mon, 8 Mar 93 01:07:49 +0100
Subject:    non-commutative Gauss algorithm

Dear GAP-forum,

is there a function  in GAP 3.2 that  takes a sequence of AG-words and
applies the non-commutative   Gauss algorithm to  it?   Checking   the
manual and browsing through the source code didn't reveal one.  I know
about the function Cgs(). Cgs() does more than I need  because it also
closes the generating system  under conjugates/commutators and powers.
The function that I have in mind just computes  the `row-echelon form'
for the given sequence of AG-words.

With kind regards, Werner Nickel.

----------------------------/|-|--|-|--|------Werner-Nickel-------------------
werner@pell.anu.edu.au     /_| |\ | |  |      Mathematics Research Section
--------------------------/--|-|-\|-|_/|------Australian-National-University--



From fceller@bert.math.rwth-aachen.de Mon Mar  8 09:02:36 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Mon, 8 Mar 93 09:02:36 +0100
Subject:    Re: non-commutative Gauss algorithm

Dear Werner,
> is there a function  in GAP 3.2 that  takes a sequence of AG-words and
> applies the non-commutative   Gauss algorithm to  it?   Checking   the

if you need a function which converts an induced generating system of
an ag group into a canonical one, you should use 'Normalize'.  But
there is no "non-commutative Gauss without commutator" for arbitrary
set of ag words. If, however, you have a homomorphic image of an
induced generating system, you could use 'HomomorphicIgs'.

best wishes
  Frank Celler



From kaup@ccucvx.unican.es Mon Mar  8 15:08:29 1993
From:       kaup@ccucvx.unican.es "Ansgar Kaup"
Date:       Mon, 8 Mar 93 15:08:29 +0100
Subject:    Degree and EuclideanDegree

I gave the following commands to GAP-3.2
gap> x := X(Rationals);; x.name := "x";;
gap> Degree(0*x^0);
-1
gap> EuclideanDegree(0*x^0);
-1

Are these answers correct ?

Ansgar



From fceller@bert.math.rwth-aachen.de Mon Mar  8 16:05:23 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Mon, 8 Mar 93 16:05:23 +0100
Subject:    Re: Degree and EuclideanDegree

Dear Ansgar,
>  gap> EuclideanDegree(0*x^0);
>  -1
>  Are these answers correct ?

In an euclidean ring R the euclidean degree is defined *only* for the
non-zero elements of R.  So one should *not* apply 'EuclideanDegree'
to the zero element of an euclidean ring, the behaviour is undefined
in this case.

> gap> Degree(0*x^0);
> -1

As there is no "-infty", -1 is used.  This is convenient in polynomial
rings and hopefully not too confusing in laurent polynomial rings.

best wishes
  Frank



From sibley@math.psu.edu Mon Mar  8 19:54:52 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Mon, 8 Mar 93 19:54:52 +0100
Subject:    Where 3.2?

I must have missed the announcement.  People here have been discussing
GAP 3.2 for quite a while now, but I can't find it at
dimacs.rutgers.edu, where I got previous versions.  Where can I get
it?

David Sibley   NT3O
sibley@math.psu.edu



From martin@bert.math.rwth-aachen.de Mon Mar  8 20:01:54 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 8 Mar 93 20:01:54 +0100
Subject:    Re: Where 3.2?

Is 'dimacs.rutgers.edu' still not up to date?  Sorry about that.  The
closest server for you is probably 'wuarchive.wustl.edu'.  There you find
GAP in the directory '/edu/math/source.code/group.theory/gap'.
'wuarchive' should never be more than a day behind
'samson.math.rwth-aachen.de', because the automatically retrieve all new
files every night.

Martin.

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



From jcbhrb@cerf.net Mon Mar  8 22:57:53 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Mon, 8 Mar 93 22:57:53 +0100
Subject:    RE: Trouble compiling GAP under DOS

gap-forum@samson.math.rwth-aachen.de
In regards to my question last week about compiling gap under DOS;
first the bad news: I could not resolve the problems I was having with the
'make' utility in spite of the help I received from Martin. The good news is
that I managed to produce an executable by other means -- not as nice as using
the standard Makefile but at least I got this to work:

 (1) compile the DOS specific subroutine
     gcc -c sysdos.c -DSYS_IS_MSDOS
 (2) compile the system independant subroutines
     gcc -c vecffe.c   gcc -c word.c     gcc -c vector.c   gcc -c unknown.c
     gcc -c tietze.c   gcc -c string.c   gcc -c set.c      gcc -c statemen.c
     gcc -c record.c   gcc -c scanner.c  gcc -c rational.c gcc -c read.c
     gcc -c polynom.c  gcc -c range.c    gcc -c permutat.c gcc -c plist.c
     gcc -c pcpresen.c gcc -c list.c     gcc -c integer.c  gcc -c gasman.c
     gcc -c idents.c   gcc -c function.c gcc -c finfield.c gcc -c cyclotom.c
     gcc -c eval.c     gcc -c blister.c  gcc -c costab.c   gcc -c aggroup.c
     gcc -c agcollec.c
 (3) compile the main program (also system independant)
     gcc -c gap.c
 (4) archive the object files of all subroutines into a "gaplib.a" archive
     ar -cr gaplib.a sysdos.o          ar -cr gaplib.a set.o
     ar -cr gaplib.a word.o            ar -cr gaplib.a agcollec.o
     ar -cr gaplib.a aggroup.o         ar -cr gaplib.a costab.o
     ar -cr gaplib.a blister.o         ar -cr gaplib.a eval.o
     ar -cr gaplib.a cyclotom.o        ar -cr gaplib.a finfield.o
     ar -cr gaplib.a function.o        ar -cr gaplib.a idents.o
     ar -cr gaplib.a gasman.o          ar -cr gaplib.a integer.o
     ar -cr gaplib.a list.o            ar -cr gaplib.a pcpresen.o
     ar -cr gaplib.a plist.o           ar -cr gaplib.a permutat.o
     ar -cr gaplib.a range.o           ar -cr gaplib.a polynom.o
     ar -cr gaplib.a read.o            ar -cr gaplib.a rational.o
     ar -cr gaplib.a scanner.o         ar -cr gaplib.a record.o
     ar -cr gaplib.a statemen.o        ar -cr gaplib.a string.o
     ar -cr gaplib.a tietze.o          ar -cr gaplib.a unknown.o
     ar -cr gaplib.a vector.o          ar -cr gaplib.a vecffe.o
     ranlib gaplib.a
 (5) produce the executable and add the DOS extender part
     gcc -o mygap gap.o gaplib.a -lpc
     aout2exe mygap

The final result is mygap.exe which should be the functional equivalent of
the standard gap.exe. This is probably more detail than most would care to 
know but hopefully this will be of some help since these commands can be 
collected into one batch file without worrying about command line length 
restrictions and the like; The executable seems to be working fine. Now I 
have to figure out why it is a full 150KByes bigger than the standard gap.exe!

Jacob Hirbawi
JcbHrb@CERF.net



From martin@bert.math.rwth-aachen.de Mon Mar  8 23:11:10 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 8 Mar 93 23:11:10 +0100
Subject:    Re: RE: Trouble compiling GAP under DOS

Jacob Hirbawi writes in his e-mail message of 1993/03/08
    In regards to my question last week about compiling gap under DOS;
    first the bad news: I could not resolve the problems I was having with the
    'make' utility in spite of the help I received from Martin. The good news is
    that I managed to produce an executable by other means -- not as nice as using
    the standard Makefile but at least I got this to work:

     (1) compile the DOS specific subroutine
         gcc -c sysdos.c -DSYS_IS_MSDOS
     (2) compile the system independant subroutines
         gcc -c vecffe.c   gcc -c word.c     gcc -c vector.c   gcc -c unknown.c
         [similar commands for the other source files]
     (5) produce the executable and add the DOS extender part
         gcc -o mygap gap.o gaplib.a -lpc
         aout2exe mygap

    The final result is mygap.exe which should be the functional equivalent of
    the standard gap.exe. This is probably more detail than most would care to 
    know but hopefully this will be of some help since these commands can be 
    collected into one batch file without worrying about command line length 
    restrictions and the like; The executable seems to be working fine. Now I 
    have to figure out why it is a full 150KByes bigger than the standard gap.exe!

I think the reason that your executable is larger than ours is that we
use the optimizing option '-O2' of 'gcc'.  This tends to decrease the
size of the executable (and it makes the executable faster too).

If you do this your executable should even be a little bit smaller than
ours, because we prepend the whole DOS extender to the executable while
'aout2exe' only adds a stub that loads the DOS extender at run time.

Martin.

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



From short@jordan.csu.murdoch.edu.au Tue Mar  9 04:51:58 1993
From:       short@jordan.csu.murdoch.edu.au "Mark Short"
Date:       Tue, 9 Mar 93 04:51:58 +0100
Subject:    Recognising small groups

Ralf Dentzer writes (in part):
> The groups I am interested in are not very big, at most some hundred
> elements, but can be rather complicated in structure.
> My first problem is to recognize some groups from the literature or other
> computations in the complete lists of (small) solvable groups (or
> p-groups) contained in GAP, so that I get a complete overview of
> the possibilities. Some of the groups are given by relations, some
> as permutation groups and some as semidirect products or otherwise.
> 
> The second problem is to recognize subgoups and/or factor groups of
> (solvable) groups in the given lists or to test isomorphism with
> other subgroups/factor groups. Especially the isomorphism test
> between subgroups should happen automatically (the groups involved
> in this are very small!)


The good news: I have code that recognises many ``small'' groups. For example,
if given GL(2,3) in any form, then (assuming any coset enumerations that might
be needed can be accomplished, and so on) it would return something like this:

Order: 48
Identifier: 48.49
Name: GL(2,3)

I won't bother to describe any more details because of the following items of
bad news:

1. The code is written in Cayley. GAP didn't have all the features I needed
when I first started the project in 1987. I think GAP has all the necessary
features now, but the code comprises 3000 lines, so I am in no hurry to make
the conversion!
   So, if you can be bothered you might want to make part of this conversion
yourself.

2. My identifiers for the groups are usually not those used by GAP. For example,
the group A_4 would come back as

Order: 12
Identifier: p^2q # 2g
Name: A(4)

(This is because an analogue of A_4 exists for many orders p^2q (where p and q
are distinct primes) and my code can recognise any such group.)
If your group has a name, then this is no problem, but if it doesn't, then you
just get an identifier, which of course is no help in recognising the group
unless you know my classification scheme!

-----

So Ralf, yes I can help you, but only if you are willing to put in a
significant amount of work!

If you want any more details please write to me directly at
short@jordan.csu.murdoch.edu.au

My apologies to other readers for going on about non-GAP issues.

Mark Short
Murdoch University
Western Australia



From short@jordan.csu.murdoch.edu.au Tue Mar  9 06:03:03 1993
From:       short@jordan.csu.murdoch.edu.au "Mark Short"
Date:       Tue, 9 Mar 93 06:03:03 +0100
Subject:    correction

A minor correction to my reply to Ralf Dentzer:
I wrote
``GAP didn't have all the features I needed when I first started the project
in 1987.''
I now recall that I didn't even know of GAP's existence until 1989!



From obrien@pell.anu.edu.au Tue Mar  9 07:18:35 1993
From:       obrien@pell.anu.edu.au "Eamonn O'Brien"
Date:       Tue, 9 Mar 93 07:18:35 +0100
Subject:    A second GAP forum?

I write to pose the question --
Is it appropriate to establish two GAP forums?

Should we have 

-- one to deal with mathematical queries, uses of 
   GAP to solve particular problems, bug reports, etc.

-- one to deal with machine specific items such as porting,
   compiliation, performance of standard tests, distribution
   of executables, etc.

The amount of correspondence generated by the GAP forum
has grown significantly over the past few months;
much of it seems to be of the second type and I'm one
of those who is primarily interested in the first.

I realise that on occasion it will be difficult
to determine the appropriate forum  for a posting --
in such circumstances, I'm sure we will not object
to people posting to both groups -- however, most 
recent postings seem to pose no difficulty in this respect.

As a regular user of GAP, I think the forum serves a very 
useful role and it is in that vein that I raise this query.

I'm interested in other subscriber opinions on this matter.

++++++++++++++++++++++++++++++++++++++++++++++
Eamonn O'Brien
++++++++++++++++++++++++++++++++++++++++++++++
School of Mathematical Sciences
Australian National University

e-mail obrien@pell.anu.edu.au
++++++++++++++++++++++++++++++++++++++++++++++



From werner@pell.anu.edu.au Tue Mar  9 08:56:40 1993
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Tue, 9 Mar 93 08:56:40 +0100
Subject:    Re:  A second GAP forum?

Dear GAP forum,
I thought it might be useful to get some statistics about the postings
to the GAP forum. Eamonn O'Brien asks if the GAP forum should be split
into two forums. I went through all the postings to the GAP forum that
were sent since the beginning of this year  and put them  into the two
categories  that Eamonn suggests.

I counted a total  of  127 postings  (discarding meaningless  postings
like   the error messages about someone's   full hard  disk, etc.). 72
postings would qualify for   the first category (mathematical  issues,
etc.)  of postings, 55 for the second category (implementation issues,
etc.).

There were 70 postings before GAP 3.2 was released. 45 of  those would
go into the first category and only 25 into the second.

Since the release  of GAP  3.2   there were 57  postings,  27 of which
belong to the first category and 30 to the second category.

The distribution of  postings before and after the  release of GAP 3.2
is interesting.  I think that what we are  seeing here is  an increase
of postings of the second category because there was  a new release of
GAP  and people have  to sort out the  various  installation problems.
Also, it is after  a new release  has become available that people are
interested in performance  questions and compare  the  old to the  new
release.  Therefore,  I expect that  the number  of  postings   of the
second category will decrease during the next weeks.

My opinion is that the volume of the GAP-forum  is acceptable and that
there is no need to split  the forum.  Furthermore, I usually  find it
easy to recognize  `uninteresting' messages from  the subject line. If
people continue  to  use keywords  (like   permutation  group problem,
performance,   compiling, DOS, etc.) as   part  of their subject  that
indicate the nature of their posting, there should not be a problem in
sifting  out  those messages  which deal  with   issues of   the first
category.

Regards, Werner Nickel.
----------------------------/|-|--|-|--|------Werner-Nickel-------------------
werner@pell.anu.edu.au     /_| |\ | |  |      Mathematics Research Section
--------------------------/--|-|-\|-|_/|------Australian-National-University--



From short@jordan.csu.murdoch.edu.au Wed Mar 10 01:22:50 1993
From:       short@jordan.csu.murdoch.edu.au "Mark Short"
Date:       Wed, 10 Mar 93 01:22:50 +0100
Subject:    Re: A second GAP forum?

I wish to register my support for Eamonn O'Brien's recent suggestion that there
be two GAP forums. I too am primarily interested in postings that fit into his
first category and would prefer not to receive postings that fit into his
second category.

Mark Short
Mathematics Programme
Murdoch University
Western Australia



From MATHURLEY@bodkin.ucg.ie Wed Mar 10 10:33:38 1993
From:       MATHURLEY@bodkin.ucg.ie "Ted Hurley"
Date:       Wed, 10 Mar 93 10:33:38 +0100
Subject:    Groups93 Galway/St-Andrews

As many readers of this list may know, an international conference on 
Group Theory (GROUPS 1993 Galway/St. Andrews) will be held at University 
College Galway from 1-14 August 1993. Short courses will be given by 
J. Alperin (Chicago), M Broue (Paris), A. Lubotzky (Jerusalem), 
P. Kropholler (QMW, London) and E. Zel'manov (Wisconsin).

A workshop on *Computational Group Theory using GAP* will be conducted by 
J. Neubueser (Aachen) and Martin Schoenert (Aachen). It is hoped to conduct 
workshops to suit all levels of expertize.

Further information and application form  may be obtained by writing to: 
Groups 93, Department of Mathematics, University College, Galway, Ireland or 
by e-mail: matward@bodkin.ucg.ie    or    groups93@dcs.st-andrews.ac.uk

The organizers wish to know approximate numbers participating  so 
that the necessary resources can be put in place, and are asking those who 
have not already registered, to do so as soon as possible.



From DARDANO@matna.na.infn.it Wed Mar 10 14:21:34 1993
From:       DARDANO@matna.na.infn.it "Ulderico Dardano"
Date:       Wed, 10 Mar 93 14:21:34 +0100
Subject:    RE: A second GAP forum?

 I think that the idea in itself of making (some) sub-forum's should be considered. I actually find that the amount of messages which I don't find interesting (for me! of course) is large enough  and hope that in future it will increase ....
			ciao

					Ulderico

----------------------------------------------
Ulderico Dardano
Dip. Matematica e Appl. "R. Caccioppoli"
Monte S. Angelo T, v. Cintia,  I-80126 Napoli - Italy
Tel: +39 81 675713 (direct)    Fax: +39 81 7662106
E-mail:  dardano@matna.na.infn.it
----------------------------------------------



From am@ime.usp.br Wed Mar 10 16:17:41 1993
From:       am@ime.usp.br "Arnaldo Mandel"
Date:       Wed, 10 Mar 93 16:17:41 +0100
Subject:    RE: A second GAP forum?

I propose a third gap forum, which would be dedicated to the proposal
of new gap forums.
.................................................................
Arnaldo Mandel                    \    am@ime.usp.br  (1st choice)
Computer Science Dep.		   \   amandel@cce.usp.br    (2nd)
Universidade de S\~{a}o Paulo	   /   mac@fpspux.fapesp.br
S\~{a}o Paulo - SP - Brazil	  /            (if all else fails)   



From martin@bert.math.rwth-aachen.de Wed Mar 10 16:34:23 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 10 Mar 93 16:34:23 +0100
Subject:    Re: A second GAP forum?

I would like to argue against splitting the GAP forum for some practical
reasons.

If I look at the log of the listserver, I see that a large number of
messages (especially messages asking for help in installing GAP or asking
about possible bugs in GAP) are sent by subscribers who have only shortly
before subscribed.  Those users will usually not be aware of the
etiquette of the GAP forum, especially since the README file says nothing
about two GAP forums.  Thus I doubt that the splitting will be effective
for messages from such new subscribers.

Like Werner I expect that the amount of messages related to distribution,
installation, porting, etc. will decrease once everybody has got GAP 3.2.
Then most of the messages should again be mathematical queries (hopefully
not bug reports ;-).

The number of messages in the GAP forum is not that high, though I admit
that it has been steadily increasing.  Also the subject lines are usually
quite informative, which makes it rather easy to kill uninteresting
messages.

I would however suggest the following.

Discussions, such as the discussion about GAP for OS/2 should, after the
initial message, be carried out by e-mail rather than in the GAP forum.
(I admit that I am such an offender myself and promise to use e-mail
rather than the GAP forum more often in the future ;-)

We write a FAQ (frequently asked questions with answers), containing
everybodies favorite question such as "Is there a version of GAP for the
Macintosh".  This would be posted every two weeks and also e-mailed
automatically to new subscribers.

We could mandate a standard format for the subject line.  E.g.,

    "Does GAP run on <machine>?"
    "Installation Problem on <machine>"
    "Bug in <function>?"

then users with sufficiently intelligent mail readers can filter out
uninteresting stuff automatically.

Martin.

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



From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar 11 15:29:41 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Thu, 11 Mar 93 15:29:41 +0100
Subject:    new GAP for OS/2 with hypertext documentation

Hello!
I have made available a slightly updated version of my OS/2 port of
GAP 3.2. It is in

ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapemx.zip.

I have also created a hypertext version of the GAP documentation for
use with OS/2's IPF (Information Presentation Facility). Since this
file is pretty big (700k compressed), I put it in a separate archive:

ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapinf.zip.


Enjoy!

Harald
--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From dentzer@polyhymnia.iwr.uni-heidelberg.de Thu Mar 11 16:02:17 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Thu, 11 Mar 93 16:02:17 +0100
Subject:    SemidirectProduct

It seems to me that for semidirect products of AG groups the operations
Embedding and Projection are not implemented.
(For permutation groups they seem to work.)
Here is an example:

gap> G:=AllSolvableGroups(Size, 64)[249];
grp_64_249
gap> N:=Subgroup(G, [G.1, G.4, G.5, G.6]);
Subgroup( grp_64_249, [ a, d, e, f ] )
gap> B:=Subgroup(G, [G.2]);
Subgroup( grp_64_249, [ b ] )
gap> phi:=IdentityMapping(B);
IdentityMapping( Subgroup( grp_64_249, [ b ] ) )
gap> GG:=SemidirectProduct(B, phi, N);
Group( g1, g2, g3, g4, h1, h2, h3, h4 )
gap> Embedding(B, GG, 1);
Error, Record: element 'Embedding' must have an assigned value at
return arg[2].operations.Embedding( arg[1], arg[2], arg[3] ) ... in
Embedding( B, GG, 1 ) called from
main loop
brk> quit;
gap> Projection(GG, B, 1);
Error, Record: element 'Projection' must have an assigned value at
return arg[1].operations.Projection( arg[1], arg[2], arg[3] ) ... in
Projection( GG, B, 1 ) called from
main loop
brk> quit;

As a workaround I use GG.embeddings resp. GG.projections.

Ralf Dentzer		dentzer@kalliope.iwr.uni-heidelberg.de



From dlj@maths.nott.ac.uk Thu Mar 11 16:10:17 1993
From:       dlj@maths.nott.ac.uk "Dr D. L. Johnson"
Date:       Thu, 11 Mar 93 16:10:17 +0100
Subject:    Re:  A second GAP forum?

This is to second Dr.O'Brien's suggestion.  Dave Johnson



From am@ime.usp.br Thu Mar 11 16:18:57 1993
From:       am@ime.usp.br "Arnaldo Mandel"
Date:       Thu, 11 Mar 93 16:18:57 +0100
Subject:    RE: new GAP for OS/2 with hypertext documentation

Harald Boegeholz writes:
 > 
 > I have also created a hypertext version of the GAP documentation for
 > use with OS/2's IPF (Information Presentation Facility). Since this
 > file is pretty big (700k compressed), I put it in a separate archive:

One of the things I miss on GAP is good online documentation, fur the
unix environment implementation.  My favorite choice would be an Emacs
info document, although I can survive other formats which allow fast
online search (thus, havin the manual online as a .dvi or .ps file
will not cut it).  Is there any hope that such a thing will ever
appear?  Maybe this IPF hypertext can be ported.

Arnaldo

.................................................................
Arnaldo Mandel                    \    am@ime.usp.br  (1st choice)
Computer Science Dep.		   \   amandel@cce.usp.br    (2nd)
Universidade de S\~{a}o Paulo	   /   mac@fpspux.fapesp.br
S\~{a}o Paulo - SP - Brazil	  /            (if all else fails)   



From fceller@bert.math.rwth-aachen.de Thu Mar 11 16:27:03 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Thu, 11 Mar 93 16:27:03 +0100
Subject:    Re: SemidirectProduct

> As a workaround I use GG.embeddings resp. GG.projections.
The  embeddings  and  projections are  bound  to  <GG>.embeddings  and
<GG>.projections   but  there   is   no  'SemidirectProductAgGroupOps'
operations record at the moment, so  that 'Projection' and 'Embedding'
will indeed not work.

best wishes
  Frank Celler



From sibley@math.psu.edu Thu Mar 11 16:49:11 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Thu, 11 Mar 93 16:49:11 +0100
Subject:    conjugacy class recognition problem

I'm trying to do something with conjugacy classes in AgGroups.  This is
in 3.1.  I still don't have 3.2 (wustl seems to be VERY busy).  If this
is fixed in 3.2, please let me know.  Here is a very simple example.

gap> g:=TwoGroup(8,4);;
gap> ConjugacyClasses(g);;
gap> t:=ConjugacyClass(g,g.3);
ConjugacyClass( Group( a1, a2, a3 ), a3 )
gap> g.conjugacyClasses[2];
ConjugacyClass( Group( a1, a2, a3 ), a3 )
gap> t = g.conjugacyClasses[2];
false
gap> Position(g.conjugacyClasses,t);
false
gap>

The point is that it doesn't recognize that the two classes are the
same, nor does it even recognize that the class generated by
ConjugacyClass is a class (in the list g.conjugacyClasses) at all.



From fceller@bert.math.rwth-aachen.de Thu Mar 11 16:58:36 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Thu, 11 Mar 93 16:58:36 +0100
Subject:    Re: conjugacy class recognition problem

> The point is that it doesn't recognize that the two classes are the
> same, nor does it even recognize that the class generated by
> ConjugacyClass is a class (in the list g.conjugacyClasses) at all.

This is bug in 3.1 which is fixed in 3.2:

gap> g:=TwoGroup(8,4);;
gap> ConjugacyClasses(g);;
gap> t:=ConjugacyClass(g,g.3);
ConjugacyClass( Group( a1, a2, a3 ), a3 )
gap> g.conjugacyClasses[2];
ConjugacyClass( Group( a1, a2, a3 ), a3 )
gap> t = g.conjugacyClasses[2];
true
gap> Position(g.conjugacyClasses,t);
2
gap> VERSION;
"Version 3 Release 2"

best wishes
  Frank Celler



From dennis@math.cornell.edu Thu Mar 11 17:04:32 1993
From:       dennis@math.cornell.edu "Keith Dennis"
Date:       Thu, 11 Mar 93 17:04:32 +0100
Subject:    RE: new GAP for OS/2 with hypertext documentation

Arnaldo Mandel   (am@ime.usp.br) writes
>One of the things I miss on GAP is good online documentation, fur the
>unix environment implementation.  My favorite choice would be an Emacs
>info document, although I can survive other formats which allow fast
>online search (thus, havin the manual online as a .dvi or .ps file
>will not cut it).  Is there any hope that such a thing will ever
>appear?  Maybe this IPF hypertext can be ported.


The previewer from ArborText does searches on strings of ordinary
characters in a dvi file (unfortunately, no accented characters
or math is accepted).  Thus you can preview dvi files AND search them.
The previewer can be bought separately (about $375 educational price).
It is also available as one of the pieces of Publisher if you happen
to already own it.

Keith Dennis



From sibley@math.psu.edu Thu Mar 11 17:14:27 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Thu, 11 Mar 93 17:14:27 +0100
Subject:    RE: new GAP for OS/2 with hypertext documentation

>
>One of the things I miss on GAP is good online documentation, fur the
>unix environment implementation.  My favorite choice would be an Emacs
>info document, although I can survive other formats which allow fast
>online search (thus, havin the manual online as a .dvi or .ps file
>will not cut it).  Is there any hope that such a thing will ever
>appear?  Maybe this IPF hypertext can be ported.

Eh?  I find the GAP online documentation to be excellent.  It's much
faster and more efficient than anything I ever experienced with EMACS
info files, where you have to know where an item is in the heirarchy.

But maybe we are talking about different things.  I'm referring to the
"?<word>" and "??<word>" runtime help facilities.  You can even read the
manual page by page using "?>".  These are extremely powerful utilities.
I find them much better than EMACS info files.  Perhaps you have not
investigated thoroughly what can be done with these.



From schumach@math.wisc.edu Thu Mar 11 19:04:06 1993
From:       schumach@math.wisc.edu "Lee Schumacher"
Date:       Thu, 11 Mar 93 19:04:06 +0100
Subject:    Re: new GAP for OS/2 with hypertext documentation

>>One of the things I miss on GAP is good online documentation, fur the
>>unix environment implementation.  My favorite choice would be an Emacs
>>info document, although I can survive other formats which allow fast
>>online search (thus, havin the manual online as a .dvi or .ps file
>>will not cut it).  Is there any hope that such a thing will ever
>>appear?  Maybe this IPF hypertext can be ported.
>
>Eh?  I find the GAP online documentation to be excellent.  It's much
>faster and more efficient than anything I ever experienced with EMACS
>info files, where you have to know where an item is in the heirarchy.
>
>But maybe we are talking about different things.  I'm referring to the
>"?<word>" and "??<word>" runtime help facilities.  You can even read the
>manual page by page using "?>".  These are extremely powerful utilities.
>I find them much better than EMACS info files.  Perhaps you have not
>investigated thoroughly what can be done with these.

The ? and ?? are quite useful, its true, but hardly a substitute for a
real structured info tree.  The problem with the GAP facilities is
that you need to know the NAME of the function or concept before you
can find it.  Of course the topic of discourse in GAP is sufficiently
narrow that this is not a problem in general.  However I did read the
manual off line first and now ? is useful more as a memory jogger.
Note that emacs info files are intended more for learing new concepts
and groups of commands or functions.  If you just want to find a
command and you have a pretty good idea what the name is then you
use apropos, which provides all of the functionality of ? and ??.

 Lee



From sibley@math.psu.edu Thu Mar 11 20:23:44 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Thu, 11 Mar 93 20:23:44 +0100
Subject:    Re: new GAP for OS/2 with hypertext documentation

>The ? and ?? are quite useful, its true, but hardly a substitute for a
>real structured info tree.  The problem with the GAP facilities is
>that you need to know the NAME of the function or concept before you
>can find it.   [rest deleted]

Not so.  Something like "??conjug" will give you a list of all
references involving conjugation, conjugacy, conjugate, etc.  I use the
?? utility this way a lot.  The reference name need not even involve
the letters "conjug", since many references have short descriptions
associated with them which involve other words and which are found by
the ?? command.  Nor do you have to get the case correct, as ?? is not
case sensitive.  Yes, you do have to know something about what you are
looking for, but certainly not the exact name.  Yes, it is very much
like "apropos".

Yes, to use the ? you need the exact name (except case does not matter,
and actually you need only a unique initial string from the name -- the
tab-key name-completion feature will help with this if you bother to
type the cases right).  You can easily get the correct name from a ??
query.  Well, yes, sometimes there are several likely-looking names, so
I check them all.  I find this a lot easier than following several
likely-looking branches in an info tree.



From am@ime.usp.br Thu Mar 11 21:48:08 1993
From:       am@ime.usp.br "Arnaldo Mandel"
Date:       Thu, 11 Mar 93 21:48:08 +0100
Subject:    Re: new GAP for OS/2 with hypertext documentation

This discussion is getting a bit out of hand.  I said some time ago:
>> One of the things I miss on GAP is good online documentation, fur the
>> unix environment implementation.  My favorite choice would be an Emacs
				     ^^^^^^^^^^^^^^^^^^
>> info document, although I can survive other formats which allow fast

There were some suggestions and some discussion, and then David Sibley
pointed out:
 > 
 > Yes, to use the ? you need the exact name (except case does not matter,
 > and actually you need only a unique initial string from the name -- the
 > tab-key name-completion feature will help with this if you bother to
 > type the cases right).  You can easily get the correct name from a ??
 > query.  Well, yes, sometimes there are several likely-looking names, so
 > I check them all.  I find this a lot easier than following several
		      ^^^^^^^^^^^^^^^^^^^^^^^^
 > likely-looking branches in an info tree.


I don't.  But the whole discussion is boiling down to a matter of
personal preferences.  Since I live most of the time within emacs, and
maintain it here, it is perhaps natural that I have become addicted to
info.  On the other hand, I will retract my complaints about lack of
"good online documentation" (I had no intention of putting down ? and
??), and qualify it instead as a "lack of an online manual of the
kind *I* find convenient".

Now, perhaps I would have kept to myself about info, if it wasn't for
the circunstance that a hypertext version of GAP documentation had been
created, for another plataform.  The source code for GAP shows that
emacs was a heavily used tool for development; maybe the developers of
GAP would have something to say on this matter.

Anyway, it is not such a big deal.

.................................................................
Arnaldo Mandel                    \    am@ime.usp.br  (1st choice)
Computer Science Dep.		   \   amandel@cce.usp.br    (2nd)
Universidade de S\~{a}o Paulo	   /   mac@fpspux.fapesp.br
S\~{a}o Paulo - SP - Brazil	  /            (if all else fails)   



From neubuese@samson.math.rwth-aachen.de Fri Mar 12 09:28:22 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Fri, 12 Mar 93 09:28:22 +0100
Subject:    Comfort in GAP

Dear GAP-forum,
In  his last  letter Arnaldo  Mandel asks  that the developers  of GAP
should comment on the discussion about online  documentation for  GAP.
Rather than leaving a technical  contribution on this problem to those
who have done the actual work in the development that is there, as the
oldest in the team I want to make a general statement:

Please do  not forget in such discussions about the wanted comfort  in
the use of GAP (the discussion on the splitting of the gap-forum and a
few others were  in  the same  line) that  GAP is developed by a small
group  of  mathematicians ("Lehrstuhl"  means  chair, and  this  is  a
correct  description,  there  is  one chair  in  mathematics  and some
assistants  and  several  students  around it  who  are developing the
central part of GAP).  This is what I have tried  to emphazise in  the
preface to  the manual, GAP is thought of as an open system  to which,
we hope, other people  will  also contribute mathematics, it is  not a
commercial product  where you can demand and buy the personal  comfort
that you personally would prefer.  We have volunteered to provide some
reasonable environment for  using GAP and in particular several  of my
young colleagues and students have devoted quite a  bit of  time (that
often enough  is hardly  recognized  as doing mathematics  in academic
proceedings) to these developments. We  do not  regret this or want to
complain now, but I just ask everybody's understanding that we do have
priorities  that  tend  more  to  implementing  new  mathematics  than
fulfilling every possible (even if quite understandable and justified)
wish for more comfort.

We are most  grateful to those colleagues who have on their  own taken
up some of the more technical  tasks  in  making GAP available or more
comfortable  to use,  for instance to Steve Linton for doing the first
portation to the DOS world, to Professor Mendelsohn's group for making
GAP available on MACs or to Harald Boegeholz for providing a hypertext
version to  name just some.  And we  welcome  of course very  much the
"share libraries" that add to its  mathematical power.   We think that
GAP can survive as an open system only if also some of  the  technical
tasks are shared by some more people than the few at Aachen and we ask
you to further help us in this way. These tasks should be discussed in
the gap-forum as  well  as - I  hope increasingly again  - mathematics
that  has been done or can be done with GAP and I think that it is not
too much of  a burden to throw away those e-mails  that do not concern
you.

A small special request in this line:  please try  to get  the  latest
version of GAP and to follow up the patches that are made available in
some  intervals; as in every larger system there are of course bugs in
GAP but quite often we do get  reports on bugs that have  already been
fixed and for  which  the fix had  been distributed.  Finding this out
does take some time  that you could  help  us  to save by  having  all
bug-fixes installed with you at the earliest possible time.

Thank you for your understanding for these matters.

Joachim Neubueser



From bro@clio.iwr.uni-heidelberg.de Fri Mar 12 10:37:30 1993
From:       bro@clio.iwr.uni-heidelberg.de "Karl Brodowsky"
Date:       Fri, 12 Mar 93 10:37:30 +0100
Subject:    RE: new GAP for OS/2 with hypertext documentation

emtex has a dvi-previewer which enables searching and which is FREE.
Running on OS-Half and on MS-dos.



From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar 12 11:13:53 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Fri, 12 Mar 93 11:13:53 +0100
Subject:    FrattiniSubgroup

The GAP function FrattiniSubgroup is not included in the manual.
I think this is due to the fact that it only works for p-groups.
Can I hope for this function to work for general AG groups
or even all finite groups sometime?
(I had some hopes that this would be included in version 3.2.)
At the moment I can compute the frattini subgroup by brute force
using ConjugacyClassesSubgroups, but is there a better way?
(And should this brute force method be included in GAP?)

Regards

Ralf Dentzer		dentzer@kalliope.iwr.uni-heidelberg.de



From neubuese@samson.math.rwth-aachen.de Fri Mar 12 13:31:42 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Fri, 12 Mar 93 13:31:42 +0100
Subject:    Re: FrattiniSubgroup

Ralf Dentzer asks: 
> The GAP function FrattiniSubgroup is not included in the manual.
> I think this is due to the fact that it only works for p-groups.
> Can I hope for this function to work for general AG groups
> or even all finite groups sometime?

This function  FrattiniSubgroup(G) does in fact exist,  and  it  works
only for p-groups which moreover must be  given as AG-groups - it will
not work  for  a p-group that is given  by generating permutations for
instance.   The reason that  it is  not included  in the  manual  (and
possibly extended by a brute force method in all  other cases)  is the
following:  Charles Leedham-Green  has  proposed the  use  of  a  very
special kind of AG-presentations  for arbitrary  soluble groups  which
among  other  things will facilitate the  computation  of  all maximal
subgroups  of a soluble group and hence  of course also  the  Frattini
subgroup.   A  student  here  in Aachen, Bettina  Eick, is at  present
implementing this and related proposals and we hope that with the next
release  of GAP her programs which indeed will  give  some further new
functions  and some improvements of  performnce for some existing ones
will  be  included. At that time then we shall try to  have a  general
function FrattiniGroup which in the cases where  we do not know better
will resort to brute force.

Ralf Dentzer continues: 
> (I had some hopes that this would be included in version 3.2.)
Me too!

> At the moment I can compute the frattini subgroup by brute force
> using ConjugacyClassesSubgroups, but is there a better way?
> (And should this brute force method be included in GAP?)
See above.

Thanks for the question, we are happy to inform about what is going on
and encourage others to do the same with work going on with them.

Joachim Neubueser

neubueser@math.rwth-aachen.de



From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar 12 14:31:41 1993
From:       dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Fri, 12 Mar 93 14:31:41 +0100
Subject:    ConjugacyClassesSubgroups

Under certain conditions the function ConjugacyClassesSubgroups doesn't
seem to work correctly. I have a subgroup U of a parent group G with the
following RecFields:

gap> RecFields(U);
[ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "parent", 
  "operations", "size", "cgs", "zuppoBlist", "isFinite", "shiftInfo", 
  "normalizer", "isAbelian", "elements", "zuppos", "trivialSubgroup", 
  "generatorZuppoBlist", "perfectSubgroups" ]
gap> RecFields(G);
[ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs", 
  "operations", "1", "2", "3", "4", "5", "name", "isAbelian", "elements", 
  "zuppos", "zuppo_generators", "zuppo_powers", "zuppo_primes", 
  "zuppo_exponents", "trivialSubgroup", "size", "generatorZuppoBlist", 
  "perfectSubgroups", "zuppoBlist", "compositionSeries", 
  "elementaryAbelianFactors", "isSolvable", "elementaryAbelianSeries", 
  "index", "isFinite", "shiftInfo", "generatorZuppos", "lattice", 
  "conjugacyClassesSubgroups", "isNormal", "factorGroup", "conjugacyClasses", 
  "normalClosure", "normalSubgroups" ]

and I get the following error:

gap> ConjugacyClassesSubgroups(U);
Error, Record: element 'zuppo_powers' must have an assigned value at
if G.zuppo_powers[pos] = false or hzup[G.zuppo_powers[pos]] ... in
H.representative.operations.SetLatticeStatus( L, H, status ) called from
SetLatticeStatus( L, C, L.classGroups ) called from
obj.operations.Lattice( obj ) called from
Lattice( G ) called from
G.operations.ConjugacyClassesSubgroups( G ) called from
..

The function works properly if I call it with

gap> ConjugacyClassesSubgroups(Group(U));

In case you are interested: G = grp_32_40 and
U = Subgroup( G, [G.1, G.2, G.4, G.5]).

Best regards
	Ralf Dentzer



From neubuese@samson.math.rwth-aachen.de Fri Mar 12 15:14:09 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Fri, 12 Mar 93 15:14:09 +0100
Subject:    Re: ConjugacyClassesSubgroups

Ralf Dentzer reports: 
> Under certain conditions the function ConjugacyClassesSubgroups doesn't
> seem to work correctly. I have a ........

Thanks  for the  warning,  we will look at  the problem  and hopefully
provide a fix with the first patch to be distributed "soon".

Joachim Neubueser



From martin@bert.math.rwth-aachen.de Fri Mar 12 17:18:13 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Fri, 12 Mar 93 17:18:13 +0100
Subject:    Re: RE: new GAP for OS/2 with hypertext documentation

Arnaldo Mandel writes in his e-mail message of 1993/03/11

    One of the things I miss on GAP is good online documentation, fur the
    unix environment implementation.  My favorite choice would be an Emacs
    info document, although I can survive other formats which allow fast
    online search (thus, havin the manual online as a .dvi or .ps file
    will not cut it).  Is there any hope that such a thing will ever
    appear?  Maybe this IPF hypertext can be ported.

I would like to know which features of GNU EMACS' info mode you miss in
GAP's on-line help.  I think that both allow roughly the same.

1)  You know exactly what you are looking for:

    In EMACS you use 'g <name-of-node>'.

    In GAP you use '?<name-of-section>'.

2)  You know roughly what you are looking for:

    In EMACS you go to one of the indices (say with 'g concept index'),
    find the most likely candidate and with 'm <choice>' you go there.

    In GAP you use '??<short string>', select the most likely candidate
    and with '?<name>' you go there.

3)  You want to browse around in the manual:

    In EMACS you go to the top node, select a section and go there
    with 'm <section>'.  In the section you again use 'm <subsection>'
    to go to the next subsection.

    In GAP you say '?chapters', select a chapter and go there with
    '?<chapter>'.  Then you read the first section of the chapter and
    find references (of the form (see "<section>")) to all the
    sections in this chapter.  Then you again use '?<section>' to
    go to the section you are interested in.

4)  You want to go to the next or previous node/section:

    In EMACS you use 'n' and 'p'.

    In GAP you use '?>' and '?<'.

5)  You want to go from a subsection to a section:

    In EMACS you use 'u'.

    In GAP you use '?<<'.

6)  You want to go from a subsection to the next node section:

    In EMACS you use 'u' and 'n'.

    In GAP you use '?>>'.

7)  You want to follow a cross reference.

    In EMACS you use 'f <reference-name>'.

    In GAP cross references are again of the form (see "<section>")
    and you use '?<section>'.

8)  You want to go to the last section that you visited before the
    current one:

    In EMACS you use 'l'.

    In GAP you use '?-'.

One feature I like in David Gillespie's enhanced EMACS's info mode (it is
not in the standard info mode) that is missing in GAP is the function
','.  With 'i' you first specify an pattern.  Then ',' lets you visit in
turn all nodes that have index entries that match this pattern.

One feature I dislike in EMACS' info mode is that I still find it
difficult to decipher the information at the top of each node which
should tell me where I am.  I find GAP's top line much easier to read.

David Sibley replied in his e-mail message of 1993/03/11

    Eh?  I find the GAP online documentation to be excellent.  It's much
    faster and more efficient than anything I ever experienced with EMACS
    info files, where you have to know where an item is in the heirarchy.

"excellent": why, thank you.  "faster": I don't think so.  In EMACS a
special file (info-file) is generated from the TeX manual.  This file
contains information that allows EMACS' info mode to go very fast from
node to node.  In GAP the online help always works from the original
LaTeX files.  To find a node it has to search the 'manual.toc' file, open
the chapter file, search linearly to the section, etc.  It seems to be
fast enough though.

Lee Schumacher replied in his e-mail message of 1993/03/11

    The ? and ?? are quite useful, its true, but hardly a substitute for a
    real structured info tree.  The problem with the GAP facilities is
    that you need to know the NAME of the function or concept before you
    can find it.  Of course the topic of discourse in GAP is sufficiently
    narrow that this is not a problem in general.  However I did read the
    manual off line first and now ? is useful more as a memory jogger.
    Note that emacs info files are intended more for learing new concepts
    and groups of commands or functions.  If you just want to find a
    command and you have a pretty good idea what the name is then you
    use apropos, which provides all of the functionality of ? and ??.

I argue that the GAP manual is tree structured (into chapters and
sections), and that the online help allows you to search through this
structure.  In the online help the top node is '?chapters', with
references to the first sections of all chapters.  And the first section
of each chapter contains references (of the form (see "<section>")) of
all the sections of this chapter.  So the tree is quite shallow (of depth
2, except in "Group", where it has depth 3), but it's a tree
nevertheless.

The chapter that you get with '?About GAP' is certainly not a reference
manual.  It's main purpose is to learn about the (new) concepts in GAP.
I know that not all sections of this chapter are easily read online, but
the first few certainly are.

Arnaldo Mandel replied in his email of 1993/03/11

    I don't [find GAP's online help more convenient than EMACS' info].
              But the whole discussion is boiling down to a matter of
    personal preferences.  Since I live most of the time within emacs, and
    maintain it here, it is perhaps natural that I have become addicted to
    info.  On the other hand, I will retract my complaints about lack of
    "good online documentation" (I had no intention of putting down ? and
    ??), and qualify it instead as a "lack of an online manual of the
    kind *I* find convenient".

    Now, perhaps I would have kept to myself about info, if it wasn't for
    the circunstance that a hypertext version of GAP documentation had been
    created, for another plataform.  The source code for GAP shows that
    emacs was a heavily used tool for development; maybe the developers of
    GAP would have something to say on this matter.

I havn't ever used OS/2's IPF.  Also Hypertext is such a buzzword.  Could
somebody enligthen me about IPF's features?

I use EMACS a lot.  Actually I probably would be lost without EMACS.I
don't think it would be too difficult to make a TeXinfo manual for GAP,
but we are certainly not considering it in the moment.  (I don't miss a
GAP info-file for EMACS, but then I probably have to use the manual less
often than others ;-).

Martin.

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



From hwb@machnix.mathematik.uni-stuttgart.de Fri Mar 12 23:58:06 1993
From:       hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz"
Date:       Fri, 12 Mar 93 23:58:06 +0100
Subject:    RE: new GAP for OS/2 with hypertext documentation

   Date: Fri, 12 Mar 93 17:22:23 +0100
   From: martin@bert.math.rwth-aachen.de (  Martin Schoenert)

   I havn't ever used OS/2's IPF.  Also Hypertext is such a buzzword.  Could
   somebody enligthen me about IPF's features?

I can, of course :-).

An IPF document is created from an ASCII file that contains certain
tags. This is done using a compiler, IPFC. The compiler is part of the
OS/2 2.0 Developer's Toolkit, i.e., not generally available for free.
The resulting .INF file can be read with OS/2's builtin VIEW command.

The finished document has the following features: It is displayed in a
window with scrollbars and buttons, i.e., can be operated conveniently
with a mouse. The document is hierarchically structured (in the case
of the GAP manual in two levels), and there is a contents window that
shows you this tree. Inside a section, text can be displayed in
several fonts (I used that for the GAP docs), and graphics.

A section can contain hypertext links, i.e., words or phrases that are
displayed in a different colour. Clicking on them with the mouse takes
you directly to the referenced section. The references "..." in the
GAP manual were of course idial candidates for conversion to such
links.

An index window is available too. This window contains an alphabetical
index made up from user specified keywords. For the GAP manual, I used
the \index entries contained in the \TeX manual. Again, clicking on an
index entry directly takes you to the referenced section.

A search function lets you search for any phrase either in the index
or in the full text of all secions. You get a list of all search hits
and can pick the desired secion(s) from that list.

IPF has quite a few more features, but I don't want to bore you too
much. 

I must point out that my INF version of the GAP documentation still
has quite a few unconverted \TeX commands in it. In particular, I made
no attempt at converting the math formulas, so they look as ugly as
they do in the regular GAP online documentation.


Hope this was of general interest.


Harald


P.S.: I will be on vacation for three weeks starting tomorrow, and
won't be able to participate in this discussion during this time.

--
Harald Boegeholz |Home:       hwb@texnix.stgt.sub.org (read daily)
                 |University: hwb@machnix.mathematik.uni-stuttgart.de
                 |please don't send large (>100k) mail to my home address.



From sibley@math.psu.edu Sun Mar 14 00:49:30 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Sun, 14 Mar 93 00:49:30 +0100
Subject:    character tables

I finally got version 3.2.  Playing with the new features, I tried
gap> g:=ThreeGroup(243,1);;
gap> t:=CharTablePGroup(g);;

It took just about an hour to construct the character table.  This is a
lot more than I am used to for groups of this size (roughly) from
version 3.1.  However, I was appalled when I looked more closely and
discovered this group is the cyclic group of order 243.  An hour to find
the character table of a cyclic group?  (This is actual running time,
according to ps.)

Is there some flaw in the method being used here?  I am a bit worried
that there might be similar performance problems if a group happens to
have a large cyclic subgroup or quotient group in the wrong place.

Note this is on a clunky old Sparcstation 1+, no speed demon, using the
binary I got from wuarchive.wustl.edu.  I haven't compiled GAP 3.2
locally yet, but I intend to.

Character tables of other groups of order 243 seem to be constructed
much faster (minute or two).  So far the cyclic one is the only one
like this I have found.

David Sibley   NT3O
sibley@math.psu.edu



From SPIT@vm.ci.uv.es Mon Mar 15 11:37:11 1993
From:       SPIT@vm.ci.uv.es "Werenfried Spit"
Date:       Mon, 15 Mar 93 11:37:11 +0100
Subject:    GAP for the Macintosh: for the impatient

Hello,
For those who want to run gap on their macintosh but cannot wait until
it is ported there, there is an alternative. Recently a port of MiNT
for the macintosh was released. This is an implementation of an
alternative OS for the atari to run on the mac; it enables the user
to run atari programmes on a macintosh (as long as these programmes
don't use the atari specific graphics (GEM) libraries). It can run
the atari executable of gap.
You can get MacMiNT by gopher from june.jpl.nasa.gov.
Two more notes:
  * You need to set the memory allocation of MiNT from 1300kByte to
    something higher than 2Mbyte to be able to run gap.ttp
  * MacMiNT is still only an alpha release, so it might be shaky (says
    its author). I haven't had any problems upto now running gap, form
    reduce and a C compiler.

A hint to gap-developers: a quick way to get a standalone version of
gap for the mac might be the approach of MacForm: this algebraic manipulation
programme was ported to the mac by making a little macintosh programme
that calls the atari ST executable of Form. In this way updates are
easily made since the mac front end need not be changed, and the compilation
of form is simple on the ST, just as in the case of gap (as explained in
chapter 47 of the gap manual).

---------------------------------------------------------------------
Werenfried Spit
   Departament de Fisica Teorica       tel: +34-6-386 4550
   Universitat de Valencia                               
---changedY
   c/ dr. Moliner, 50               e-mail: spit@vm.ci.uv.es
   46100 Burjassot, Valencia                spit@ific.uv.es
   Espanya                                  spit@evalun11.bitnet
---------------------------------------------------------------------



From ahulpke@bert.math.rwth-aachen.de Mon Mar 15 14:49:21 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Mon, 15 Mar 93 14:49:21 +0100
Subject:    Re: character tables

Dear GAP-Forum,
in his letter, David sibley wrote:
 
> gap> g:=ThreeGroup(243,1);;
> gap> t:=CharTablePGroup(g);;
> 
> It took just about an hour to construct the character table.  This is a
> lot more than I am used to for groups of this size (roughly) from
> version 3.1.  However, I was appalled when I looked more closely and
> discovered this group is the cyclic group of order 243.  An hour to find
> the character table of a cyclic group?  (This is actual running time,
> according to ps.)

Naturally, it is disappointing, if an algorithm shows poor performance in
trivial cases. However, this special example will also run as fast (or better:
as slow) in GAP-3.1.
To explain this seemingly strange behaviour, one has to look
a bit inside the algorithms:

Computing character tables can be a very tedious task. Especially, there are
some time consuming subroutines, that have to be called very often (like
identification of a class). Thus, the routines do some pre-computation to
make things faster afterwards. However, if you are dealing with an abelian or
even a cyclic group, these computations, do not need to be done, as one can
write down the appropriate character table from scratch. The only real
'task' to be done is attaching the classes of the group to the appropriate
column of the character table.

Thus the question would be: Why doesn't the routine detect, that computation
will be that simple? 
CharTablePGroup is a routine, that computes the character table, using the
algorithm of U. Baum as explained by Thomas Breuer in some previous mail to
the forum. In the next version (hopefully, this was left out of 3.2 due to time
reasons and since the computation of character tables of cyclic groups was
not very high on our schedule), the general dispatcher CharTable will provide
an all-purpose routine for computing character tables. This implies, that
computations will be shortened for abelian groups. A routine like
CharTablePGroup still will exist, and provide the specific algorithm, which
might result in poor performance for specific examples.

> Is there some flaw in the method being used here? 

I would not call this behaviour a 'flaw'. CharTablePGroup is a specific
routine. Adding examinations of special cases to this routine will result in
poorer performance in all other cases, since the test for this special case
must be run always. The handling of these special cases is a task of the
more general dispatcher. The user may then choose, if he uses the general,
or a specific routine: The general routine is slower, but takes the task of
selecting a specific routine itself (though this selection might be not
as perfect, as the one done by a human). It is just a question, how thinking
is divided between human and computer.

> I am a bit worried
> that there might be similar performance problems if a group happens to
> have a large cyclic subgroup or quotient group in the wrong place.

This behaviour most likely will reappear, if the group has a large cyclic
factorgroup. To cope with this beaviour surely is part of the DWIM (Do What
I Mean) problem (baptized this way by Charles Leedham-Green):
If I ask the computer to compute the character table of a large abelian
group, most likely, I'm not interested in a long list of irreducible
characters (unless I want to check memory allocation routines...).
The information, I can make use of, would be, that the group *is* abelian, 
that the structure is Z_a x Z_b x ..., and maybe in *some* irreducible
characters, from which the other ones can be obtained by tensor products.
If I have a group with a large cyclic factorgroup, either the group itself
is very large --- then the cyclic factor will not count --- or the cyclic
factor is of disproportional size, compared to the normal subgroup. Then the
group most likely is of some special structure, and much more information
can be gained, if I use this special structure.
Of course this implies, that special algorithms for special structures
should be available, i.e. the program should behave 'intelligent'. 
Reaching that point will mean *a lot* of work, I do not even dare to
estimate.

Finally, I still did not answer, how to cope with this behaviour (unless
one wants to wait centuries for the finished GAP 3.$\infty$). I can only
give some suggestions for coping with it:
Before computing a character table, I would check, how many conjugacy classes
the group has. In the problematic cases, the group will have a lot of classes.
Afterwards one can decide, if one *really* wants the character table of that
kind of group. (In case if one wants it, there still is the question,
whether the table should be computed from the group --- which is only
necessary, if one wants a correspondence of class representatives and columns
--- or whether one will compute the table itself by CharTableDirectProduct
or similar.)
In case, this does not help for your particular problem, feel free to ask;
maybe there is a problem, we never thought about.

I hope this rather lengthy pamphlet has shed some light on this problem. 

     Alexander Hulpke



From sibley@math.psu.edu Mon Mar 15 22:23:15 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Mon, 15 Mar 93 22:23:15 +0100
Subject:    bug in TransformingPermutations?

This is with 3.2 running on a Sun Sparcstation 1+ with the distributed
binary obtained from wuarchive.wustl.edu.  Looks like it is asking for
the length of a non-existant list.  Other than that, I have no idea
what the trouble is.

I'd appreciate a workaround.


gap> g:=ThreeGroup(243,4);;
gap> h:=ThreeGroup(243,5);;
gap> gt:=CharTablePGroup(g);;
gap> ht:=CharTablePGroup(h);;
gap> x:=TransformingPermutationsCharTables(gt,ht);
Error, List Element: <list>[6] must have a value at
return Length( fam1.permutations[x] )
  <> Length( fam1.permutations[bij_rows[x]] ) ... in
func( l ) called from
ForAny( [ 1 .. Length( bij_rows ) ], function ( x ) ... end ) called from
TransformingPermutations( tbl1.irreducibles, tbl2.irreducibles ) called from
TransformingPermutationsCharTables( gt, ht ) called from
main loop
brk>



From sibley@math.psu.edu Mon Mar 15 23:07:50 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Mon, 15 Mar 93 23:07:50 +0100
Subject:    Re: Bug in TransformingPermutations?

It looks like the problem may actually be with ForAny.  From what I can
see in the documentation, the following should work (returning false)
but does not.  It's not clear that this is the same bug.  The error
message is different.


gap> a:=[1,2];
[ 1, 2 ]
gap> ForAny([a,a,,,a,a],x->Length[x]>2);
Error, List Element: <position> must be a positive integer at
return Length[x] > 2 ... in
func( l ) called from
ForAny( [ a, a,,, a, a ], function ( x ) ... end ) called from
main loop
brk>



From sibley@math.psu.edu Mon Mar 15 23:22:33 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Mon, 15 Mar 93 23:22:33 +0100
Subject:    Re: Bug in TransformingPermutations?

Arrgh.  Ignore that about ForAny.  Soon I hope to learn the difference
between parentheses and square brackets.



From martin@bert.math.rwth-aachen.de Mon Mar 15 23:53:23 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 15 Mar 93 23:53:23 +0100
Subject:    Re: bug in TransformingPermutations?

David Sibley writes in his e-mail message of 1993/03/15
    This is with 3.2 running on a Sun Sparcstation 1+ with the distributed
    binary obtained from wuarchive.wustl.edu.  Looks like it is asking for
    the length of a non-existant list.  Other than that, I have no idea
    what the trouble is.

    I'd appreciate a workaround.

    gap> g:=ThreeGroup(243,4);;
    gap> h:=ThreeGroup(243,5);;
    gap> gt:=CharTablePGroup(g);;
    gap> ht:=CharTablePGroup(h);;
    gap> x:=TransformingPermutationsCharTables(gt,ht);
    Error, List Element: <list>[6] must have a value at
    return Length( fam1.permutations[x] )
      <> Length( fam1.permutations[bij_rows[x]] ) ... in
    func( l ) called from
    ForAny( [ 1 .. Length( bij_rows ) ], function ( x ) ... end ) called from
    TransformingPermutations( tbl1.irreducibles, tbl2.irreducibles ) called from
    TransformingPermutationsCharTables( gt, ht ) called from

This function was written by Tomas Breuer and I don't pretend to fully
understand it, so take my comments with a grain of salt.

It seems that this problem can only happen if there is no transforming
permutation.  I hope this is enough of a workaround.

More background.  'TransformingPermutations' first groups the characters
of each table in families.  Two characters are in a family if they are
equal when sorted (e.g., '[1,-1,1,-1]' is in the same family as
'[1,1,-1,-1]', but not in the same family as '[1,-1,-1,-1]').  A
necessary condition for the existence of a transforming permutation is a
bijection between the list of families, i.e., every family of 'gt' must
also be a family of 'ht' (this is tested twice), and every family of 'ht'
must also be a family of 'gt' (this is *not* tested).  The test that
fails is the test that the corresponding families of 'gt' and 'ht' also
have the same number of characters in them.

David writes in another e-mail message of 1993/03/15

    It looks like the problem may actually be with ForAny.  From what I can
    see in the documentation, the following should work (returning false)
    but does not.  It's not clear that this is the same bug.  The error
    message is different.

    gap> a:=[1,2];
    [ 1, 2 ]
    gap> ForAny([a,a,,,a,a],x->Length[x]>2);
    Error, List Element: <position> must be a positive integer at

And in yet another e-mail message

    Arrgh.  Ignore that about ForAny.  Soon I hope to learn the difference
    between parentheses and square brackets.

Have you been using Mathematica lately? ;-)

Martin.

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



From am@ime.usp.br Tue Mar 16 00:10:55 1993
From:       am@ime.usp.br "Arnaldo Mandel"
Date:       Tue, 16 Mar 93 00:10:55 +0100
Subject:    Re: RE: new GAP for OS/2 with hypertext documentation

  Martin Schoenert writes:
[an interesting comparison of emacs info and GAP'S on-line help]

First of all, this comparison and your later comments on how much
you use emacs are bound be an enticement for those GAPers (?) who are
not emacs users to try it out :-)

Let me see what I think I miss from info on GAP.  First of all, the
familiar interface. I have learned already an uncountable number (even
though it is finite) of user interfaces on several classes of similar
programs; it is not so difficult to keep them straight as long as they
are used frequently, but it sure is boring.  Anyway, GAP's keycodes
aren't even close to the torture of using vi *occasionaly*, something
I have to cope with, so let it be.

On this site, the X interface of GNU Emacs is all souped up with
goodies I have come to get used.  Thus, for some stuff, like following
chapters, references and other hypertext links, the mouse comes in
handy.  And one can add hyperbole buttons in such a way that an info
file can have attached postscript or dvi files, which would be shown
in the screen adequately.

And then, I can easily pluck pieces of an info file into a buffer (but
this is cheating, since I already said I use a mouse, I can pick up
stuff from an xterm too).

 > I use EMACS a lot.  Actually I probably would be lost without EMACS.I
 > don't think it would be too difficult to make a TeXinfo manual for GAP,

I am flabbergasted!  I thought it would be a HUGE amount of work, given
the size of the GAP manual.  Actually, that was the main reason I
never asked for it, until I was prompted by the posting about hypertext.

 > but we are certainly not considering it in the moment.  (I don't miss a

Joachim's last posting surely set the priorities straight. The lack of
an info is at most a very minor deficiency of GAP; surely the team
energies are better spent into improving GAP's mathematical abilities
and computational power.

 > GAP info-file for EMACS, but then I probably have to use the manual less
 > often than others ;-).

Saved yourself a backache from carrying a 2 kg GAP manual up and down
:-)

Best regards,

Arnaldo

.................................................................
Arnaldo Mandel                    \    am@ime.usp.br  (1st choice)
Computer Science Dep.		   \   amandel@cce.usp.br    (2nd)
Universidade de S\~{a}o Paulo	   /   mac@fpspux.fapesp.br
S\~{a}o Paulo - SP - Brazil	  /            (if all else fails)   



From ahulpke@bert.math.rwth-aachen.de Tue Mar 16 18:26:03 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Tue, 16 Mar 93 18:26:03 +0100
Subject:    CharTablePGroup and abelian groups

			    He tried the instruments as no one else had tried
			    them; he destroyed them, one after another, as
			    fast as they could be made and sent him, till the
			    patience of Mr. Sholes [the inventor] was
			    exhausted.
			    But Mr. Densmore insisted, that this was the very
			    salvation of the enterprise; that it showed the
			    weak spots and defects, and that the machine must
			    be made so that anybody could use it, or all
			    efforts might as well be abandoned; that such a
			    test was a blessing and not a misfortune, for
			    which the enterprise should be thankful.

			    Donald A. Norman, The design of everyday things

Dear GAP-Forum,

A few days ago, David Sibley noted a somehow strange behaviour in
CharTablePGroup, whenever occuring an abelian group. I tried to answer this
letter in pointing out, that computing a character table of an abelian group
perhaps is not an too good idea. However, further analysis led to the
conclusion, that this effect could not be resposible for a behaviour *that*
bad. 
An examination of the execution of the algorithm showed, that there was
indeed an flaw, which was responsible not only for the poor performance on
the cyclic group, but also for a decerease of speed in the general case.

As a result, the thus modified algorithm runs about a factor 2-15 (15 for
abelian groups) faster, than the former version, resulting in an improvement
in speed about at least the factor 3-4 in the 'mean' case. (These factors are
based on computing the character tables of all groups of order 243).

I'd like to thank David Sibley for pointing us to this case. We depend on
the aid of users for finding errors like these, that may remain undetected
when running examples.

Alexander Hulpke



From jcbhrb@cerf.net Wed Mar 17 05:52:18 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Wed, 17 Mar 93 05:52:18 +0100
Subject:    Infinite matrix groups

gap-forum@samson.math.rwth-aachen.de
The section "About Matrix Groups" in the manual says :

" ... Especially inifinite matrix groups (over the rationals or cyclotomic
  fields) can not be dealt with at all. "

Now what I am trying to do is not very complicated : starting with a small
number of rational matrices which I know generate an infinite group, I'd
like to get the first 1000 or so elements (as generated by any algorithm 
for now; later I would like add some selection rules). Is this also impossible? 
if it is then which of the "internal" programs should I look at to get an 
idea of what's involved?. Thanks.

Jacob Hirbawi
JcbHrb@CERF.net

PS. This has to do with a number of problems in crystallography that I'd like
    to look at using GAP. If anyone else has done any work along these lines
    or has any suggestions please let me know. Thanks.



From neubuese@samson.math.rwth-aachen.de Wed Mar 17 09:35:46 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed, 17 Mar 93 09:35:46 +0100
Subject:    Re: Infinite matrix groups

Jacob  Hirbawi  asked  about  the possibility  to calculate  with  the
elements  of  an  infinite  matrix group over  the rationals.  That is
indeed  possible  as  well  as  the  calculation  with  matrices  over
cyclotomic fields,  it is just that most of the general group functions
cannot be used. Frank Celler is answering that in more detail.
 
However,in a PS you say that this has  to do with a number of problems
in crystallography  and since  in the  past  I  have  been working  on
crystallographic groups making heavy use of computer methods (e.g. for
the classification of the four-dimensional point and space groups),  I
am curious to know  what  you are after.  possibly  we or others might
even have some suggestions how to use GAP for the problems.

Joachim Neubueser



From fceller@bert.math.rwth-aachen.de Wed Mar 17 10:02:15 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Wed, 17 Mar 93 10:02:15 +0100
Subject:    Re: Infinite matrix groups

Dear Gap Forum,
Jacob Hirbawi asked about a way to construct the first 1000 elements
of an infinite matrix group.

It is true, that the 'Random' function will not work for infinite
matrix groups, because 'Random' (and many other matrix group
functions) try to construct an isomorphic permutation group.  However,
if you have a matrix of finite order you can asked for its order.  But
if your matrix has a very large orbit, this function will run for
ages, because it constructs orbits in order to find the order of the
matrix.

In order to construct elements of an infinite matrix group, one could
form random products in the generators.  I have found to following
heuristic useful for matrix groups over finite fields: Create a
product of 100 * Length(G.generators) randomly chosen generators as
seed, and multiply this seed from the left or right (again randomly
chosen) with a random generator for the next element.

This random function is used in a program which will try to decide
whether a given group over a finite field contains the SL or not.  If
your group is called G the following program will generate 1000
Elements of G:

  E := [];
  while Length(E) < 1000  do
      AddSet( E, RecSL.Random(G,0) );
  od;

As this function 'RecSL.Random' does not invert the generators, you
might want to add the inverses of the generators of your matrix group
to the generators of G.  As you are (maybe) not interested in (pseudo)
random elements, you should skip the seed generating process by starting
with the identity as seed element:

  G := Group( m1, ..., mn );
  G.randomSeed := G.identity;

best wishes
  Frank Celler



From dfh@maths.warwick.ac.uk Wed Mar 17 10:42:34 1993
From:       dfh@maths.warwick.ac.uk "Derek Holt"
Date:       Wed, 17 Mar 93 10:42:34 +0100
Subject:    Re:  Infinite matrix groups

The problem as stated was to get the `first' 1000 or so elements of an
infinite matrix group rather than a random collection of elements.
Suppose the matrix group  G  is generated by  g_1,...,g_n.
It seems to me that the natural way to do this is to start with the
free group  F  on generators  x_1,...,x_n, and define the obvious
epimorphism  phi  from  F  to  G.  Now generate the first 1000 or so elements
of  F, using the usual length-lexicographic ordering, and take the images
of these words under  phi.

There are two problems. Firstly, there does not currently appear to be a GAP
function to spew out elements in a free group in order, although there probably
should be, and it would not be too hard to write. Secondly, if the matrix
group  G  has nontrivial relations, then the list of elements in  G  produced
will have some repetitions. If only about 1000 elements are needed, then it
would not be difficult to look for these repetitions directly (perhaps using
hash tables).

Better still, if one knows defining relations for  G, then the Knuth-Bendix
procedure can be used to generate all relations in  G  systematically, and
then it is possible to produce repetition-free lists directly. Of course,
this is not yet possible in the GAP system, but the relevant software
does exist. We have used this technique to good advantage at Warwick in
connection with automatic groups.  It has led to spectacular improvements
in efficiency in programs which draw pictures for analysts and topologists,
etc.

Derek Holt.



From neil@dehn.mth.pdx.edu Wed Mar 17 18:21:33 1993
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Wed, 17 Mar 93 18:21:33 +0100
Subject:    Group rings of AG-Groups

I have need to do calculations with group rings of ag-groups.  Does GAP know
how to deal with this already or am I looking at defining a new domain?  If
someone has already done something with this, I would appreciate knowing what
it is.

--John Neil



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



From ahulpke@bert.math.rwth-aachen.de Wed Mar 17 18:43:15 1993
From:       ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke"
Date:       Wed, 17 Mar 93 18:43:15 +0100
Subject:    Re: Group rings of AG-Groups

In his message, John Neil asked:
> 
> I have need to do calculations with group rings of ag-groups.  Does GAP know
> how to deal with this already or am I looking at defining a new domain?  If
> someone has already done something with this, I would appreciate knowing what
> it is.
> 
Group Rings are not a built-in object. If the groups, in which you want to
compute are not too big (basically this means, that you can keep a list of
all group elements in memory at the same time and you are prepared to wait
for multiplications --- multiplication is done by simple distributive
expansion of sums, thus requires a lot of products to be computed), I can
provide some basic routines, I wrote some time ago. They provide a group
algebra as an vector space of dimension $|G|$, the basis corresponding to
the group elements. Thus elements are represented as sums of group elements.
Supported operations are almost only the basic ring operations +, -, *.

Alexander Hulpke



From geck@dmi.ens.fr Thu Mar 18 08:34:08 1993
From:       geck@dmi.ens.fr "Meinolf Geck"
Date:       Thu, 18 Mar 93 08:34:08 +0100
Subject:    J.Neils question about computations in group rings

Dear Prof. Neil,
in GAP-3.2 there is a package containing programs for working with
Weyl groups and associated Hecke algebras. The latter are certain deformations
of the group ring of the first. There are programs to do computations
in this algebra, e.g. multiplying two basis elements and expressing the
result as a linear combination of the basis vectors. (I am not certain
whether or not GAP has already some built-in functions for comptations
in group rings). Maybe looking at the code or the documented examples
in the chapter 'Weyl group and Hecke algebras' of the manual might help you?

Sincerely yours, Meinolf Geck

(Lehrstuhl D f"ur Mathematik, RWTH Aachen)



From neubuese@samson.math.rwth-aachen.de Thu Mar 18 10:05:34 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Thu, 18 Mar 93 10:05:34 +0100
Subject:    Re: Group rings of AG-Groups

There have been already two attempts  to answer  J.   Neil's  question
about possibilities of calculating in group rings of AG groups. Let me
give a third hint: Martin Wursthorn at Stuttgart (working in the group
of  Prof. Klaus Roggenkamp) has a set  of standalone programs  written
for the investigation of modular group rings of *p-groups* (given by a
polycyclic presentation) which e.g.   computes automorphism  groups of
p-groups but  also  unit  groups  of such  group rings.  Together with
Martin  Wursthorn  we  are  planning  to  make this  set  of  programs
available as a further "share library" through GAP in the  not too far
future. Maybe this is of interest.

Joachim Neubueser



From kaup@ccucvx.unican.es Thu Mar 18 18:13:29 1993
From:       kaup@ccucvx.unican.es "Ansgar Kaup"
Date:       Thu, 18 Mar 93 18:13:29 +0100
Subject:    ? Bug in ElementProperty ?

I gave the following GAP-Commands :
gap> a:=(1,2)(3,5)(4,6)(7,10);;
gap> b:=(2,3,4)(5,7,8)(6,9,10);;
gap> G:=Group(a,b);;
gap> PermGroupOps.ElementProperty(G,g->a^g=a);
()
gap> C:=Centralizer(G,a);
Subgroup( Group( ( 1, 2)( 3, 5)( 4, 6)( 7,10), ( 2, 3, 4)( 5, 7, 8)
( 6, 9,10) ), [ ( 3, 4)( 5, 6)( 7,10)( 8, 9), ( 1, 2)( 3, 5)( 4, 6)( 7,10) ] )
gap> c1:=C.generators[1];;
gap> c2:=C.generators[2];;
gap> a^c1;
( 1, 2)( 3, 5)( 4, 6)( 7,10)
gap> a^c2;
( 1, 2)( 3, 5)( 4, 6)( 7,10)


I think that the command PermGroupOps.ElementProperty should have returned 
one of the two generators of C or at least a product of them.
Is there an Error or do I make anything wrong ?

Saludos,
        Ansgar



From martin@bert.math.rwth-aachen.de Thu Mar 18 18:21:25 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 18 Mar 93 18:21:25 +0100
Subject:    Re: ? Bug in ElementProperty ?

Ansgar Kaup asks in his e-mail message of 1993/03/18:
    I gave the following GAP-Commands :

    gap> a:=(1,2)(3,5)(4,6)(7,10);;
    gap> b:=(2,3,4)(5,7,8)(6,9,10);;
    gap> G:=Group(a,b);;
    gap> PermGroupOps.ElementProperty(G,g->a^g=a);
    ()

    I think that the command PermGroupOps.ElementProperty should have returned 
    one of the two generators of C [the centralizer of a]
    or at least a product of them.
    Is there an Error or do I make anything wrong ?

You get what you ask for.  You want an element that centralizes 'a', you
get one.  Not only that.  In fact you even get the *smallest* such
element (but this is not guaranteed).  Maybe you want to rewrite your
test as 'g->a^g=a and g <> ()'?.

Martin.

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



From jcbhrb@cerf.net Fri Mar 19 08:46:16 1993
From:       jcbhrb@cerf.net "Jacob Hirbawi"
Date:       Fri, 19 Mar 93 08:46:16 +0100
Subject:    Infinite matrix groups

gap-forum@samson.math.rwth-aachen.de
Thanks to Joachim Neubueser, Frank Celler, and Derek Holt for their 
responses regarding my question on infinite matrix groups. I'd like
to make these comments in return:

(1) I think the first method suggested by Derek Holt is very close to what I
    had in mind for getting the 'first' 1000 elements of an infinite group;
    I will try generating more and more elements of the free group while
    watching for repetitions (until I get 1000). As noted there doesn't
    seem a GAP function that does that, but I agree that it should be easy 
    to implement one; an advantage of this is that I know how to add 
    'selection rules' for which elements to accept.  I was hoping to find 
    something more sophisticated and it seems that such an algorithm exists.
    Two catches though! : it is not part of GAP (yet), and it assumes that
    you know the defining relations of the group (for this particular problem,
    I don't, I only have matrices). This algorithm would be a nice addition
    to GAP someday; in the mean time I would be interseted to know more about
    the existing software and I think that others might be too. I'll leave it
    to Derek's discretion to tell more about his software by e-mail or through
    the forum -- when he's not too busy of course :-)

(2) Frank Celler's heuristic method would probably involve the least amount of
    work on my part and so I will try it first. I suspect that this would not
    really give me the elements that I am looking for but hopefully I'm wrong!

(3) I am glad to get a response from Dr. Neubueser on this since I am well
    aware of his work (with others) on the classification of the the four 
    dimensional space groups; this also makes it easier for me to describe 
    my "wish-list" as far as crytallographic groups are concerned: the 
    short (and and I hope not too blunt :-) ) answer is : all the tables
    in the book 'Crystallographic Groups in Four Dimensional Space'; 
    It would be so nice to have the generators for all the point groups
    as well as the full space groups in dimensions 1 to 4 complemented by
    routines to give such standard data as equivalent positions (for 
    different cernterings) of these groups -- that would make a good part
    of the International Tables available at your fingertips. 

    I realize that the classification was carried out a number of yeares 
    before GAP was introduced; I am curious to know how much of it can be 
    recreated within GAP today. 

Once again, thanks to all for their help.

Jacob Hirbawi
JcbHrb@CERF.net



From leh@aberystwyth.ac.uk Fri Mar 19 10:49:11 1993
From:       leh@aberystwyth.ac.uk "Lee Hawkins"
Date:       Fri, 19 Mar 93 10:49:11 +0100
Subject:    Linear combinations in Gap

To The Gap Forum,

Hope this question is not too trivial for the forum, but I'm not very
experienced with Gap.

My problem is the following : 

I have a list of lists, each of which I wish to express as a Z-linear
combination of a set of given lists (each list involved consists of
integers). How can I do this in Gap 3.2 ?????

Any help appreciated, thanx in advance,

Lee Hawkins (Dept. of Pure Mathematics, University of Wales, Aberystwyth, UK)



From sam@ernie.math.rwth-aachen.de Fri Mar 19 12:45:34 1993
From:       sam@ernie.math.rwth-aachen.de "Thomas Breuer"
Date:       Fri, 19 Mar 93 12:45:34 +0100
Subject:    Re: Linear combinations in Gap

Dear Mrs. and Mr. Forum,
Lee Hawkins writes in his mail

>  I have a list of lists, each of which I wish to express as a Z-linear
>  combination of a set of given lists (each list involved consists of
>  integers). How can I do this in Gap 3.2 ?????

Let 'X' be an integral matrix with linearly independent rows, and 'b' an
integral vector of same dimension as the rows of 'X'.  The GAP function
'Decomposition' computes the integral coefficient vector 'a' (if exists)
such that 'a * X = b'.

The method used is p-adic approximation, that is, a square submatrix of 'X'
of full rank is inverted modulo a suitable prime p, and the initial part
of the p-adic series of a solution 'a' is computed.  If no solution is found
then 'false' is returned, what means that either no integral solution exists
or the maximal length of the computed initial part was chosen too small.
The details can be found in the GAP manual in section "Decomposition".

It should be noted that 'X' need not be integral, the algorithm also works
for matrices over the ring of cyclotomic integers.

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



From digne@dmi.ens.fr Mon Mar 22 14:20:52 1993
From:       digne@dmi.ens.fr "Francois Digne"
Date:       Mon, 22 Mar 93 14:20:52 +0100
Subject:    Leonard Soicher's Package for computing graphs automorphisms

Dear Gap-forum
I have been told that Leonard Soicher has written a GAP package for
computing automorphism groups of graphs. Where could I get it?
Francois Digne



From sl25@cus.cam.ac.uk Mon Mar 22 14:48:30 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Mon, 22 Mar 93 14:48:30 +0100
Subject:    Re: Leonard Soicher's Package for computing graphs automorphisms 

It's available for anonymous FTP from galois.maths.qmw.ac.uk in directory /pub.
The filenames are grape.README and grape.tar.Z.

The actual automorphism group calculations are performed by calling
Brendan McKay's nauty program.

	Steve Linton



From sl25@cus.cam.ac.uk Tue Mar 23 17:04:13 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Tue, 23 Mar 93 17:04:13 +0100
Subject:    Inconsistencies in new string, list and range features.

1) While strings are lists, string literals do not appear to be 
usable as such:

gap> "abc"[1];
Syntax error: ; expected
"abc"[1];
     ^
gap> ("abc")[1];
Syntax error: ; expected
("abc")[1];
       ^
gap> l := "abc";
"abc"
gap> l[1];
'a'

Actually the second example above seems to be an instance of
something more general:

gap> (l)[1]; 
Syntax error: ; expected
(l)[1];
   ^

2) I think the following should work:

gap> [y := 9, y-1 ..1];
Syntax error: ] expected
[y := 9, y-1..1];
    ^
This may look stupid, but suppose 9 were replaced by an expensive
function call.

gap> y := 9; [y,y-1..1];
9
[ 9, 8 .. 1 ]

works, but seems unnecessarily long.

Actually, the best way to cope with this situation would be to be
able to specify the step explicitly in a range literal, something
like [start, end : step].

	Steve



From martin@bert.math.rwth-aachen.de Tue Mar 23 19:25:06 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 23 Mar 93 19:25:06 +0100
Subject:    Re: Inconsistencies in new string, list and range features.

Steve Linton writes in his e-mail message of 1993/03/23

    1) While strings are lists, string literals do not appear to be 
    usable as such:

    gap> "abc"[1];
    Syntax error: ; expected
    "abc"[1];
         ^

This is not a problem of strings.  The same ``problem'' appears with any
list.  I.e., '[2,3,5,7,11][3]' is also not allowed.  The BNF syntax shows
you that left of the '[' there must be a *variable*, i.e., either
'<identifier>', '<variable>.<identifier>', or '<variable>.[<expr>]'.  It
would be possible to change the parser to allow something like
'<list-literal>[<expr>]', but frankly this doesn't seem very important.

Steve Linton continues:

    2) I think the following should work:

    gap> [y := 9, y-1 ..1];
    Syntax error: ] expected
    [y := 9, y-1..1];
        ^
    This may look stupid, but suppose 9 were replaced by an expensive
    function call.

    gap> y := 9; [y,y-1..1];
    9
    [ 9, 8 .. 1 ]

    works, but seems unnecessarily long.

    Actually, the best way to cope with this situation would be to be
    able to specify the step explicitly in a range literal, something
    like [start, end : step].

Since ranges are internally stored as triple <low>, <high>, <inc>, a
syntax of the form '[ <low> .. <high> by <inc> ]' would not pose any
difficulties.  Maybe some day.

Martin.

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



From rbiggers@kscsuna1.kennesaw.edu Wed Mar 24 16:49:33 1993
From:       rbiggers@kscsuna1.kennesaw.edu "Ronald Biggers"
Date:       Wed, 24 Mar 93 16:49:33 +0100
Subject:    Permutation Representations of Wreath Products

Dear Gap Forum,
     I am presently using the DOS version of GAP 3.1.  What must I do to 
correct the following error(s)?

gap> z2 := Group( (1,2) );;
gap> z2.name := "z2";;
gap> g4 := Group( (1,3)(2,4), (1,2)(3,4) );;
gap> g4.name := "g4";;
gap> i4 := IdentityMapping( g4 );;
gap> g8 := WreathProduct(z2, g4, i4);;
gap> gt1 := Subgroup( g8, [
> WreathProductElement( (1,2), (), (), (), (), () ),
> WreathProductElement( (), (1,2), (), (), (), () ),
> WreathProductElement( (), (), (1,2), (), (), () ) ] );;
gap> gt1.name := "gt1";;
gap> x1 := Set( RightCosets( g8, gt1 ) );;
gap> Operation( g8, x1, OnRightCosets );
Error, for: <list> must evaluate to a list at
for <var> in set ... in
opr( D[i], gen ) called from
arg[1].operations.Operation( arg[1], arg[2], arg[3] ) called from
Operation( g8, x1, OnRightCosets ) called from
main loop
brk>
     .
     .
     .
gap> Permutation( WreathProductElement( (1,2), (), (), (), (1,3)(2,4),
> (1,3)(2,4) ), x1, OnRightCosets );
Error, for: <list> must evaluate to a list at
for <var> in set ... in
opr( D[i], g ) called from
D.operation.Permutation( arg[1], arg[2], arg[3] ) called from
Permutation( WreathProductElement( (1,2), (), (), (), (1,3)(2,3), (1,3)(2,
4) ), x1, OnRightCosets ) called from
main loop
brk>

Ron Biggers

Ronald C. Biggers
Associate Professor of Mathematics
Kennesaw State College
P.O. Box 444
Marietta, GA  30061
(404)423-6505 or 6327
Fax (404) 423-6629



From kaskel@math.berkeley.edu Wed Mar 24 23:22:47 1993
From:       kaskel@math.berkeley.edu "Bruce Kaskel"
Date:       Wed, 24 Mar 93 23:22:47 +0100
Subject:    problems running GAP on a PC

I've recently been trying to install GAP on my PC (486).
I've set up the gapexe.386 executable and the \lib and \grp libraries.

Hopefully someone out there has been through this and can answer some questions

1) I have not been able to correctly access the grp library.
   I do not get an error message but the machine simply 'freezes'.
	For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt
        and nothing happens.
 
   Martin Sch"onert advised me to remove my TSR's and EMM386. I tried this
   and a variety of other combinations but it's still no good.

   Can anyone point out what I might be doing wrong?

2) I am currently just trying to get the gapexe.386 port running.
   However since I am putting it on a 486 I wonder:
	I assume that gapexe.386 was compiled with 387 emmulation.
	Is this correct?
	If so, how much 'speed improvement'/'program size savings' is achieved
		by compiling for a 387?
	

Thanks in advance for any help offered.

Bruce Kaskel
kaskel@math.berkeley.edu



From sl25@cus.cam.ac.uk Thu Mar 25 11:06:22 1993
From:       sl25@cus.cam.ac.uk "Steve Linton"
Date:       Thu, 25 Mar 93 11:06:22 +0100
Subject:    Re: problems running GAP on a PC 

> 
> 2) I am currently just trying to get the gapexe.386 port running.
>    However since I am putting it on a 486 I wonder:
> 	I assume that gapexe.386 was compiled with 387 emmulation.
> 	Is this correct?
> 	If so, how much 'speed improvement'/'program size savings' is achieved
> 		by compiling for a 387?
> 	

The DOS extender detects the presence or otherwise of a 387 at
run-time and looks for a software emulator only if one is needed.

In any event, I don't believe that GAP uses any floating point at
all.

	Steve



From L.H.Soicher@qmw.ac.uk Thu Mar 25 11:49:33 1993
From:       L.H.Soicher@qmw.ac.uk "Leonard Soicher"
Date:       Thu, 25 Mar 93 11:49:33 +0100
Subject:    Re: problems running GAP on a PC

>1) I have not been able to correctly access the grp library.
>   I do not get an error message but the machine simply 'freezes'.
>	For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt
>        and nothing happens.
	 

In your batch file to run gap, you should specify the library as

         -l /lib/

(or whatever).  The important thing is to use "/", so that the gap 
system can modify the string containing the  lib  directory to 
determine the  grp  directory. 


L.H.Soicher@qmw.ac.uk



From martin@bert.math.rwth-aachen.de Thu Mar 25 12:08:58 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 25 Mar 93 12:08:58 +0100
Subject:    Re: Permutation Representations of Wreath Products

Ronald Biggers writes in his e-mail message of 1993/03/24
    gap> z2 := Group( (1,2) );;
    gap> z2.name := "z2";;
    gap> g4 := Group( (1,3)(2,4), (1,2)(3,4) );;
    gap> g4.name := "g4";;
    gap> i4 := IdentityMapping( g4 );;
    gap> g8 := WreathProduct(z2, g4, i4);;
    gap> gt1 := Subgroup( g8, [
    > WreathProductElement( (1,2), (), (), (), (), () ),
    > WreathProductElement( (), (1,2), (), (), (), () ),
    > WreathProductElement( (), (), (1,2), (), (), () ) ] );;
    gap> gt1.name := "gt1";;
    gap> x1 := Set( RightCosets( g8, gt1 ) );;
    gap> Operation( g8, x1, OnRightCosets );
    Error, for: <list> must evaluate to a list at

Once upon a time right cosets weren't domains in GAP.  They were simply
proper sets (i.e., sorted lists).  'OnRightCosets' then was the function
to use for those sets.  That is 'OnRightCosets' takes a proper set,
multiplies all its elements with <g>, sorts the resulting list, and
returns this as the result.

Of course representing right cosets as lists was a stupid idea,
especially if the subgroup was large (or even infinite).  Thus we changed
this (between GAP 3.0 and 3.1), so that right cosets are now domains.  To
find the ``image'' of a right coset <C> under an element <g> you can now
write '<C> * <g>'.  Thus you should use 'OnRight' instead of
'OnRightCosets'.

    gap> Operation( g8, x1, OnRight );
    Group( (4,8), (3,7), (2,6), (1,5), (1,3)(2,4)(5,7)(6,8),
           (1,2)(3,4)(5,6)(7,8) )

Note that GAP 3.2 is a little bit more clever.  If both <G> and <H> are
permutation groups, then 'WreathProduct( <G>, <H>, <alpha> )' will
automatically be represented as a permutation group.

    gap> g8 := WreatProduct( z2, g4, i4 );
    Group( (1,2), (3,4), (5,6), (7,8), (1,5)(2,6)(3,7)(4,8),
           (1,3)(2,4)(5,7)(6,8) )

So you don't have to go through 'gt1' and 'x1' to compute a permutation
representation any more.  On the other hand if you still want to define
'gt1' you now have to specify it as 'Subgroup(g8,[(1,2),(3,4),(5,6)])'.

Martin.

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



From martin@bert.math.rwth-aachen.de Thu Mar 25 12:37:35 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 25 Mar 93 12:37:35 +0100
Subject:    Re: problems running GAP on a PC

Bruce Kaskell writes in his e-mail of 24-Mar-93
    I've recently been trying to install GAP on my PC (486).
    I've set up the gapexe.386 executable and the \lib and \grp libraries.

    Hopefully someone out there has been through this and can answer some
    questions

    1) I have not been able to correctly access the grp library.
       I do not get an error message but the machine simply 'freezes'.
    	For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt
            and nothing happens.

       Martin Sch"onert advised me to remove my TSR's and EMM386. I tried this
       and a variety of other combinations but it's still no good.

       Can anyone point out what I might be doing wrong?

I am sorry, I misunderstood your e-mail.  When you wrote that you ``could
not use any of the *group functions*'', I interpreted that as ``could not
use any of the *library functions*''.

You should write the library path in your batch file that starts GAP
using slashes '/' instead of backslashes '\'.  This is because
'lib/init.g' computes the group path by replacing 'lib/' in 'LIBNAME' by
'grp/'.  In any case, start GAP and look at the variables 'LIBNAME' and
'GRPNAME' to see that they make sense.

But why would GAP freeze if the 'GRPNAME' is wrong?  If I try it here,
I just get an error message.

Bruce Kaskel continues:

    2) I am currently just trying to get the gapexe.386 port running.
       However since I am putting it on a 486 I wonder:
    	I assume that gapexe.386 was compiled with 387 emmulation.
    	Is this correct?
        If so, how much 'speed improvement'/'program size savings' is achieved
    		by compiling for a 387?

GAP doesn't use any floating point.  So there will be no speed
improvement.  One probably could use a version of 'go32' (the DOS
extender) without floating point emulation, but I doubt that the gain in
program size is worth the effort.

Martin.

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



From mendel@ccu.umanitoba.ca Thu Mar 25 19:06:32 1993
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Thu, 25 Mar 93 19:06:32 +0100
Subject:    GAP on the Mac

The second version of GAP on the Mac is now available.  To obtain it use
anonymous ftp to address ccu.umanitoba.ca  It is archived at
/pub/mac/MacGAP31.sea.hqx  Make sure to read the Read Me file. Included is
the program and the lib file but not the doc file which you can add on your
own.  Features are slide bars for scrolling, 'save transcript' and 'save
selection'. Also many cut and paste features of the Mac.  The porting was
carried out by Harry Lakser. If you have any difficulties or find bugs
please contact me and copy message to Lakser or writ to Lakser direct.  His
address is 
hlakser@ccu.umanitoba.ca
N. S. Mendelsohn



From mendel@ccu.umanitoba.ca Thu Mar 25 21:07:26 1993
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Thu, 25 Mar 93 21:07:26 +0100
Subject:    GAP on Mac

In my last letter I forgot to mention that if there is sufficient interest
Lakser will port GRAPE to Mac.  While the first transfer was an arduous job
our experience will make future transfers more or less routine. In
particular as soon as GAP 3.2 is implemented on our main-frame it will be
ported to the Mac.
N. S. Mendelsohn



From martin@bert.math.rwth-aachen.de Fri Mar 26 12:57:21 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Fri, 26 Mar 93 12:57:21 +0100
Subject:    Upgrade for GAP 3.2 (V3R2) to patchlevel 1 (V3R2P1)

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

The upgrade is available as  file  'upg3r2p1.dif.Z'  on the  'ftp' server
'samson.math.rwth-aachen.de'.  It should be  available on the other 'ftp'
servers soon.  This time I do not send out this  upgrade as e-mail, it is
simply too large (about 100 KBytes 'compress'-ed).

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

Martin.

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



From dana@bimacs.cs.biu.ac.il Tue Mar 31 15:14:39 1993
From:       dana@bimacs.cs.biu.ac.il "Dana-Picard Noah"
Date:       Tue, 30 Mar 93 15:14:39 +0200
Subject:    GAP on PC

I'm trying to run GAP on a 486 (I got the .exe file); in order to have the new upgrading, I suppose that it's necessary to ftp the .exe again. 
Is there something else to do?
Thanks,
Thierry Dana-Picard.



From dana@bimacs.cs.biu.ac.il Tue Mar 30 15:24:47 1993
From:       dana@bimacs.cs.biu.ac.il "Dana-Picard Noah"
Date:       Tue, 30 Mar 93 15:24:47 +0200
Subject:    Loewy Series

I know that the Loewy series of a group can be computed with the help
of a certain central series (Jennings's thm). 
Is there either some feature in GAP which determines this series for a
given group or somebody who already wrote a GAP program for that
purpose?

Thanks in advance for any help,

Thierry Dana-Picard. 



From fceller@bert.math.rwth-aachen.de Tue Mar 30 18:18:32 1993
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 30 Mar 93 18:18:32 +0200
Subject:    Re: GAP on PC

Dana-Picard Noah asked

    I'm trying to run GAP on a 486 (I got the .exe file); in order to have
    the new upgrading, I suppose that it's necessary to ftp the .exe
    again.

The executables on "samson.math.rwth-aachen.de" are still the old
Patchlevel 0 versions.  We will try to update the executables as soon
as possible, but it will take a few more days.  However, if you have
GCC 2.3.? installed on your PC, you can apply "upg3r2p1.dif.Z" to the
source and recompile the kernel.

    Is there something else to do?

All you need is a running compress, patch program, and
"upg3r2p1.dif.Z".  Instruction on how to apply the patch are giving at
the beginning of this files.

best wishes
  Frank Celler



From neubuese@samson.math.rwth-aachen.de Tue Mar 30 18:39:45 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue, 30 Mar 93 18:39:45 +0200
Subject:    Re: Loewy Series

Thierry Dana-Picard asked:
 
> I know that the Loewy series of a group can be computed with the help
> of a certain central series (Jennings's thm). 
> Is there either some feature in GAP which determines this series for a
> given group or somebody who already wrote a GAP program for that
> purpose?

There is no  function in  the  present  version of GAP  to compute the
Jennings series  of a p-group or the  Loewy series of its  group ring,
while in our old system SOGOS we have a command for the computation of
the Jennings series  and from it the *dimensions* of the Loewy series.
However both are so easily  implemented  in GAP that Frank Celler will
do that  right  now and send  you the functions.  Also these functions
with full description  will probably be put  into the next  patch.  To
compute the  Loewy series  itself  is a different  matter, this  would
involve computation  in the group ring itself and there are no special
provisions for that in GAP at present, so we  will not  embark on that
now. I hope that perhaps the dimensions will do?

Joachim Neubueser



From webb@s5.math.umn.edu Tue Mar 30 21:04:46 1993
From:       webb@s5.math.umn.edu "Peter Webb"
Date:       Tue, 30 Mar 93 21:04:46 +0200
Subject:    Loewy series and representation theory

In connection with Thierry Dana-Picard's question about finding Loewy series,
I have written several GAP routines which handle group representations which
in particular will compute the Loewy series of any representation of a
p-group in characteristic p (and more generally the Loewy series of the
largest quotient of a module all of whose composition factors are trivial).
The algorithm I use is simply to multiply repeatedly by the augmentation
ideal. The trouble with this approach if one is interested in the Loewy
series of the group ring is that the regular representation has a large
dimension, and for reasons of time and storage the problem may become
computationally unfeasible that way. Jenning's theorem could be the better
approach!

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

Peter Webb
webb@math.umn.edu



From sibley@math.psu.edu Tue Mar 30 22:15:04 1993
From:       sibley@math.psu.edu "David Sibley"
Date:       Tue, 30 Mar 93 22:15:04 +0200
Subject:    error in README

I was just browsing the README file distributed with GAP 3.2.  In the
list of ftp sites, it claims that wuarchive.wustl.edu is the University
of Tennessee.  However, it is the Washington University of St. Louis:

% whois wustl.edu
Washington University (WUSTL-DOM)
   Office of the Network Coordinator
   One Brookings Drive
   Campus Box 1048
   St. Louis, MO 63130-4899

[much more info, deleted to save space]



From martin@bert.math.rwth-aachen.de Wed Mar 31 09:34:25 1993
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 31 Mar 93 09:34:25 +0200
Subject:    Re: error in README

David Sibley wrote in his e-mail message of 1993/03/30

    I was just browsing the README file distributed with GAP 3.2.  In the
    list of ftp sites, it claims that wuarchive.wustl.edu is the University
    of Tennessee.  However, it is the Washington University of St. Louis:

    % whois wustl.edu
    Washington University (WUSTL-DOM)
    [...]

Mmm, yes.  Prof. Larry Husch, one of the moderators of the Mathematics
Archives on 'wuarchive.wustl.edu' asked us whether it would be ok to put
GAP on 'wuarchive.wustl.edu'.  He is from the Univ. of Tennessee.  This
is the source of our confusion.  I corrected this in the 'README' file.

Thanks, Martin.

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



From neubuese@samson.math.rwth-aachen.de Wed Mar 31 10:05:15 1993
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed, 31 Mar 93 10:05:15 +0200
Subject:    CGT workshop in Galway

On March 10, Ted Hurley posted a brief announcement of  the  Groups'93
Galway/St.Andrews meeting in this forum  in  which he  mentioned  that
during the second week  we would organize a workshop  on Computational
Group Theory using GAP. Here is a tentative plan for this workshop.

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

                          Workshop 

          Computational Group Theory and the use of GAP

                   during the second week of 

                 Groups 1993  Galway/St.Andrews

                     August 9 - 13, 1993.


The workshop  is  intended to  introduce  group  theoreticians to  the
algorithmic  methods  presently  available for  the  investigation  of
finite groups  and their (ordinary and modular) representations and of
finitely presented groups as well as to practical application  of such
methods  using  the  program  system  GAP   (Groups,  Algorithms,  and
Programming). Accordingly the workshop will offer both, several series
of  lectures describing the  mathematics underlying the algorithms and
their  implementations, and exercises at the  terminal in applying GAP
to group theoretical problems. In detail:

There will be 5 such series of lectures,  partly in parallel,  each of
about 8 periods of 45 minutes, on the following topics: 

-  Permutation groups.
   (A. Seress)
-  Collecting methods for finitely presented and polycyclic groups.
   (J. Neubueser and M.F. Newman)
-  Finitely presented Groups: Coset table methods, Knuth Bendix, 
   Automatic Groups.
   (D. Holt and J. Neubueser)
-  Representation theory.
   (K. Lux and H. Pahlings)
-  Programming in GAP.
   (M. Schoenert)

In addition we plan  5 exercise classes, three  for people with little
or no  experience in the use  of computers in group theory, which will
begin with a common introduction to GAP and then separate according to
the  interest of  participants  in finite groups,  finitely  presented
groups, or representation theory.  Further, there will be one exercise
class for people with  some  experience,  which  will  supplement  the
lecture  series  'Programming  in  GAP'.   While  for  all these  four
exercise  classes we  intend  to  provide some exercises and problems,
finally,  mainly  in the second part  of the week, we intend to run an
exercise class  'Bring your own problem', in which we will try to give
advice  how  to  use  group  theoretical  software  on  problems  that
participants  are interested in (with  no  warranty of success!!).  Of
course moving between these exercise classes will be possible.

A tentative time schedule for the workshop looks as follows: 

Monday to Thursday:

8.30 - 10.00 in parallel:  
'Finitely Presented Groups'  and  'Representation Theory'.

10.30 - 12.00 in parallel:
'Collection Methods' and 'Programming in GAP'.

13.30 - 15.00  Permutation Groups.

15.15 - 18.00  Practical exercises.
               

On Friday  morning  there will be  lectures on algorithms drawing from
all the various  methods, on the use  of Computer Algebra systems like
MAPLE for  generic calculations, and  on some new developments for the
investigation of matrix groups.

Terminals and  help with their use will  still be available on  Friday
afternoon.

For attending  the  workshop  you should  register with  'Groups  1993
Galway/St.Andrews';  no  special  registration  for  the  workshop  is
necessary, but  please  do tick  the  relevant box in the registration
form for 'Groups 1993 Galway/St.Andrews'.

The GAP system  is available  free of  charge  (including source,  the
manual and  several  executables)  through anonymous  ftp. If you want
information  about GAP, its availability on various computers, and how
to get it,  please get the  file 'pub/gap/README' from the  ftp server
'samson.math.rwth-aachen.de'  by logging in as  user  'ftp' with  your
e-mail address as password.

If you have any further  questions with regard to the workshop, please
contact:
               neubueser@math.rwth-aachen.de 
(Prof. J. Neubueser,  Lehrstuhl D fuer Mathematik,  RWTH Aachen,
Templergraben 64, D 5100, Aachen, Germany.  Tel. +49/241/804543)


 Joachim Neubueser,  Martin Schoenert



From pluto@mibtt1.mathematik.uni-stuttgart.de Wed Mar 31 10:19:56 1993
From:       pluto@mibtt1.mathematik.uni-stuttgart.de "Martin Wursthorn"
Date:       Wed, 31 Mar 93 10:19:56 +0200
Subject:    Re: [dana@bimacs.cs.biu.ac.il: Loewy Series]

> I know that the Loewy series of a group can be computed with the help
> of a certain central series (Jennings's thm). 
> Is there either some feature in GAP which determines this series for a
> given group or somebody who already wrote a GAP program for that
> purpose?
> 

As for p-groups I have written a GAP procedure to compute the Jennings
series of such groups using the fact that it is isomorphic to the
Lazard series L_n(G) = \prod_{ip^j \ge n}\gamma_i(G)^{p^j}. The
calculations are straightforward in GAP.
Furthermore there is a function to test whether a given pc-presentation
for the group is compatible with the Jennings series. In this case
such a presentation can be used (by a theorem of Jennings) to compute
a basis for the group algebra over GF(p), which is compatible with the
Loewy series. This approach has been implemented in the SISYPHOS
program developped in Stuttgart to investigate characteristic p group
algebras of p-groups. It is planned to distribute the program as a
GAP shared library.

Martin Wursthorn
Mathematisches Institut B
Universit"at Stuttgart



From white@mcs.kent.edu Wed Mar 31 22:58:05 1993
From:       white@mcs.kent.edu (Donald White)
Date:       Wed, 31 Mar 93 22:58:05 +0200
Subject:    installation problem

Our systems people have tried to install GAP 3.2 on an HP 9000/730 and
were unable to get it to compile. They gave me the following message:
> Specific problem is we are running hpux 9.0 and they apparently only support
> through 8.0.  The program compiles without complaint and then hangs and
> causes a segmentation fault and dumps core when it runs.  Sounds like a
> stray pointer...
We compiled GAP 3.1 under the old operating system last year with no
problem, but it won't compile now either.

Any suggestions??

-- Don White


