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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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 m 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