This file contains the mails sent to the GAP forum in January-March 1996.

Name                Email address                           Mails   Lines
Martin Schoenert    Martin.Schoenert@Math.RWTH-Aachen.DE       14    1310
Alexander Hulpke    Alexander.Hulpke@Math.RWTH-Aachen.DE        8     422
Franz Gaehler       gaehler@orphee.polytechnique.fr             8     384
W. David Joyner     wdj@sma.usna.navy.mil                       4     360
Frank Celler        Frank.Celler@Math.RWTH-Aachen.DE            4     162
Istvan T. Hernadvolgyi u640486@csi.uottawa                      3     235
Heiko Theissen      Heiko.Theissen@Math.RWTH-Aachen.DE          3     188
Joachim Neubueser   Joachim.Neubueser@Math.RWTH-Aachen.DE       3     188
Thomas Breuer       Thomas.Breuer@Math.RWTH-Aachen.DE           3      60
Sebastian Egner     egner@ira.uka.de                            2     260
Volkmar Felsch      Volkmar.Felsch@Math.RWTH-Aachen.DE          2     172
Andrew Mathas       a.mathas@ic.ac.uk                           2     145
Leonard Soicher     leonard@qmw.ac.uk                           2      68
Michael B. Cherkassoff mikec@math.ubc.c                         2      37
Eric Nordberg       nordbeem@caa.mrs.umn.edu                    2      14
Philip Osterlund    osterlu@s5.math.umn.edu                     1     114
Burkhard Hoefling   hoefling@mat.mathematik.uni-mainz.de        1     110
Derek Holt          dfh@maths.warwick.ac.uk                     1      78
Matthew Johnson     mejohnsn@netcom.com                         1      56
Michael Smith       michael.smith@maths.anu.edu.au              1      39
Eamonn O'Brien      eamonn.obrien@maths.anu.edu.au              1      33
Ernesto P. Adorio   adorio@math.upd.edu.ph                      1      32
Helmut Geyer        helmut.geyer@iwr.uni-heidelberg.de          1      29
Dima Pasechnik      pasec@can.nl                                1      16
Jasper Cramwinckel  jasper@win.tue.nl                           1      14
Peter F. Mueller    pfm@math.ufl.edu                            1      14
Erhard Aichinger    erhard@bruckner.stoch.uni-linz.ac.at        1      12
Stuart M. Margolis  margolis@bimacs.cs.biu.ac.il                1      11
Steve Linton        sal@dcs.st-andrews.ac.uk                    1      10
Andreas Hoppe       hoppe@math.tu-berlin.de                     1       7
TOTAL                                                          77    4580

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 erhard@bruckner.stoch.uni-linz.ac.at Sun Jan  7 18:36:27 1996
Date:           Sun, 07 Jan 96 18:36:27 +0100
From:           "Erhard Aichinger" <erhard@bruckner.stoch.uni-linz.ac.at>
Subject:        Group tables by Thomas and Wood

Dear Forum,

I am using
   TwoGroup (32, 6)
to get the 6th group of order 32. Do you
know whether the numbering of groups in the twogroup-package is
identical to the numbering in the book
  Thomas, A.D., and  Wood G.V.,  Group Tables, Shiva Publishing Ltd. ?

Best regards,
Erhard Aichinger



From joachim.neubueser@math.rwth-aachen.de Mon Jan  8 19:30:48 1996
Date:           Mon, 08 Jan 96 19:30:48 +1553
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Re: Group tables by Thomas and Wood

Erhard Aichinger asked:

> I am using
>    TwoGroup (32, 6)
> to get the 6th group of order 32. Do you
> know whether the numbering of groups in the twogroup-package is
> identical to the numbering in the book
>   Thomas, A.D., and  Wood G.V.,  Group Tables, Shiva Publishing Ltd. ?

The answer is : no, the numbering schemes are non-identical.

According to  their preface, Thomas  and Wood follow  the numbering in
Hall/Senior (The  groups of   order 2^n,  n<=6), except  for   abelian
groups.

The numbering in the  two-groups library of GAP is  the one by  Newman
and O'Brien which is  determined by their specific p-group  generation
algorithm.  (see remark and    references in the description  of   the
two-group library in the chapter 'Group Libraries' of the GAP manual).

You  can get some information   about  different namings by using  the
function 'GroupId', described in the chapter 'Groups' in the manual.

So for   the group obtained in  GAP  by TwoGroup (32, 6)  the function
GroupId gives (i.a.) 'catalogue := [32, 46]'  and the group has indeed
number 46 both in Hall/Senior and in Thomas/Wood.

Note   however   that  for  abelian  groups there   are   still little
differences  in the numbering by Hall/Senior  and  the number given by
the entry  'catalogue'.  Therefore for abelian  groups you should best
use the function 'AbelianInvariants',  also  described in the  chapter
'Groups' in  the  manual, to  see  what you  have got.  This  function
should, however,  ONLY BE APPLIED  TO ABELIAN GROUPS,   as said in the
manual. If you are not sure if your group is abelian you can first use
the function 'IsAbelian' to test this.

WARNING: At   present the function  'AbelianInvariants' applied   to a
nonabelian group will  sometimes (e.g. for  finitely presented groups)
determine the abelian invariants of  its commutator factor group,  but
sometimes it may  produce  some rather ununderstandable  error message
and,  worst  of   all, for  nonabelian  ag groups  it  may  produce  a
syntactically innocent looking wrong result.  We  intend to change the
function so that it will always produce the  abelian invariants of the
commutator  factor group,  but this  will   only be in a   forthcoming
release.

Sorry for the inconvenience, but agreeing  about a naming scheme, such
as in Chemistry, is too difficult for mathematicians.

Joachim Neubueser



From leonard@qmw.ac.uk Tue Jan  9 16:56:42 1996
Date:           Tue, 09 Jan 96 16:56:42 +0000 (GMT)
From:           "Leonard Soicher" <leonard@qmw.ac.uk>
Subject:        small bug

Hi all,

The logfile below shows a small bug in gap3r4p3 (and probably earlier
versions), and a way around this bug.

Regards,   Leonard.

gap> F:=FreeGroup(0);
Group( IdWord )
gap> Size(F);
1
gap> PresentationFpGroup(F);
Error, Record: element 'relators' must have an assigned value at
grels := G.relators ... in
PresentationFpGroup( F ) called from
main loop
brk> quit;
gap> PresentationFpGroup(F/[]);
<< presentation with 0 gens and 0 rels of total length 0 >>
gap> quit;



From a.mathas@ic.ac.uk Tue Jan  9 13:54:40 1996
Date:           Tue, 09 Jan 96 13:54:40 +0000
From:           "Andrew Mathas" <a.mathas@ic.ac.uk>
Subject:        specht 1.0

I have just uploaded a new version, specht-1.0.tar.gz, of my SPECHT
package to the incoming directory at Aachen removing the bugs from
the version I put up there in December (if someone at Aachen could
remove the older versions I would be grateful).

This is a pre-release of the SPECHT package. The routines in this package
are pretty much state-of-the-art for calculating the decomposition numbers
for Hecke algebras of the symmetric groups prior to October 1996. Around
this time it became known (and was proved) that there was an easy algorithm
for calculating these decomposition numbers over fields of characteristic
zero. I am in the process of making this algorithm fully functional within
the "SPECHT environment". I hope to have this done by early February; until
then I am making this package available partly so that I can get some
feedback on the package.

As it stands, the package is fully functional; it is just missing the
Lascoux-Leclerc-Thibon algorithm for decomposition numbers over fields
of characteristic zero (the code for this is written but not yet fully
compatible with the general package...).

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



From egner@ira.uka.de Wed Jan 10 18:13:44 1996
Date:           Wed, 10 Jan 96 18:13:44 +0100
From:           "Sebastian Egner" <egner@ira.uka.de>
Subject:        [no subject]

# Dear GAP-forum,
#
# the PermGroupOps.Normalizer function of gap3r4p1 may be
# improved to handle cyclic groups of low degree more efficiently.
# Maybe this has already been done in a later releases?
#
#   Sebastian Egner.

# Lemma:
#   Let u in G be of order r then the normalizer of <u> in G is
#
#     N(G, <u>) =
#       DisjointUnion(
#         C(G, u)*x[k] :
#           1 <= k < r and gcd(k, r) = 1 and
#           the equation u^x = u^k has a solution x[k] in G
#       )
#
#   where C(G, u) denotes the centralizer of u in G.
#
# Proof (elementary, easy):
#   1. Consider c in C(u) so u^c = u. Then calculate
#      u^(c*x[k]) = (u^c)^x[k] = u^x[k] = u^k ==> c*x[k] in N(<u>).
#   2. Conversely consider x in N(<u>). Then u^x = u^k for some
#      k in {0, .., r-1} and ord(u^k) = ord(u^x) = ord(u) = r implies
#      gcd(k, r) = 1. In addition u^x[k] = u^k = u^x implies
#      u = u^(x*x[k]^-1) and hence x*x[k]^-1 in C(u) or equivalently
#      x in C(u)*x[k]. q.e.d.

# Comments:
#   * The equation a^x = b can be solved quickly using a BSGS.
#   * Centralizers are much faster to compute than Normalizers.
#   * There are Phi(r) many equations to be solved.
#   * Let n be the number of points moved by u. Define rmax(n)
#     to be the maximal order of a permutation on n points. Observe
#        rmax(  1) = 1
#        rmax(  2) = 2
#        rmax(  3) = 3
#        rmax(  4) = 3
#        rmax(  5) = 6
#        rmax(  6) = 6
#        rmax(  7) = 7
#        rmax(  8) = 15
#        rmax(  9) = 15
#        rmax( 10) = 30
#        rmax( 12) = 42
#        rmax( 14) = 42
#        rmax( 16) = 105
#        rmax( 18) = 210
#        rmax( 20) = 210
#        rmax( 30) = 2730 ; no *not* use the proposed function
#        rmax( 40) = 15015
#        rmax( 50) = 51870
#        rmax( 60) = 570570
#        rmax( 70) = 1385670
#        rmax( 80) = 9699690
#        rmax( 90) = 20281170
#        rmax(100) = 223092870
#     So the bottom line is:
#       * If rmax(n) <= 20 then always use the conjugation method.
#       * Otherwise compute Phi( OrderPerm( u ) ) and use other
#         methods if this exceeds some bound (say 200).
#       * The computation of Phi can often be avoided by using a
#         lower bound on Phi which comes down
#         to Phi(r) > 200 for r > 1000.

# NormalizerCyclePermGroup( <permgroup>, <cyclic-subgroup> )
#   computes the normalizer of the subgroup in the permgroup.

NormalizerCyclicPermGroup := function ( G, U )
  local u, # generator of U
        r, # order of u
        k, # counter for the k with gcd(k, r) = 1
        T, # transversal of N(G, U)/C(G, u)
        t; # element of T

  # get generator of U and its order
  u := U.generators[1];
  r := OrderPerm(u);
  if r = 1 then
    return G;
  fi;

  # decide on the method
  if r > 1000 or Phi(r) > 200 then
    return Normalizer(G, U); # good luck!
  fi;

  # compute transversal of N(G, U)/C(G, u)
  T := [];
  for k in PrimeResidues(r) do
    t := RepresentativeOperation(G, u, u^k);
    if t <> false then
      Add(T, t);
    fi;
  od;

  # N(G, U) = < C(G, u) union T > by the lemma
  Append(T, Centralizer(G, u).generators);
  return Subgroup(G, T);
end;

# A simple example:
#   G  := SymmetricGroup(10);
#   U  := Subgroup(G, [( 1, 3, 8, 6, 5, 7, 2,10, 4)]);
#   N1 := NormalizerCyclicPermGroup(G, U); time;
#   --> 1980   (2 seconds)
#   N2 := Normalizer(G, U); time;
#   --> 105540 (1.5 minutes)



From alexander.hulpke@math.rwth-aachen.de Thu Jan 11 15:06:33 1996
Date:           Thu, 11 Jan 96 15:06:33 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: S.Egner [no subject]

Dear GAP-Forum,

Sebastian Egner wrote:

# the PermGroupOps.Normalizer function of gap3r4p1 may be
# improved to handle cyclic groups of low degree more efficiently.
# Maybe this has already been done in a later releases?

[code omitted]

First,  I'd like to thank you for providing your code. Indeed the
original normalizer performs abysmal in such situations (for  ex-
ample  take  the  normalizer of Z_23 in M_23), your routine shows
that this can be enormously improved. As it might be of interest,
some comments about the normalizer routine:

>From version 3.4 to 3.4.1 the normalizer has not undergone major
improvements. Our current development version contains a  greatly
improved normalizer routine, written by Heiko Theissen. (The rou-
tines use partition  backtrack  methods,  introduced  by  Jeffrey
Leon.) The new routines are to be released with GAP 4, mainly be-
cause they utilize small but subtle  changes  in  the  stabilizer
chain  concept to be introduced then.  These new routines usually
yield (based on my experiences with them) a speedup of 2 or  more
when applying the routines for normalizers in the symmetric group
(or large wreath products). The improvement for cyclic groups  is
even higher: For example the normalizer N_G(U) for

# as smaller degrees are too fast for timing
G:=SymmetricGroup(100);
U:=Subgroup(G,[Product(G.generators)]);

takes  (on a 50Mhz 486PC)  3200ms  in  our  experimental version.
(I did not want to wait for the 3.4 version,  it  certainly  will
be   MUCH slower ...) Your version, however, takes only 800ms  on
the same machine.

Your observation remains valid even in a more general context: If
U<=G, then N_G(U)/C_G(U) is isomorphic to a subgroup  of  Aut(U).
Centralizer computations are easier than normalizer computations.
Thus if we know enough  about   the   automorphism    group    to
guess    subgroups  (close  supergroups)  for N_G(U)/C_G(U), then
we can take these subgroups and  check  which subgroups are actu-
ally  induced  by  G-conjugation.  For this purpose we'll have to
find representatives of conjugating elements.  This  is   however
again  in  cost  similar to centralizers. So, if the automorphism
group is smaller in size than G, it might be worth  to  use  this
approach.

For  cyclic  groups  your algorithm implements this, guessing the
whole automorphism group and searching for suitable elements.  If
|U|  becomes larger this might also become expensive. An easy im-
provement is to run through all subgroups of  Aut(U)  (which  are
easily parametrized) and to check for subgroup generators if they
are induced by conjugacy in $G$. (This is described in  more  de-
tail  in:  G.Butler,  An inductive scheme for computing conjugacy
classes in permutation groups, Math. Comp. 62 (1994),  363--383.)
Thus the loop

  for k in PrimeResidues(r) do

in  your algorithm would be changed into a loop over subgroups of
Z_r^imes and another loop over their generators. This should give
another  speedup,  especially  if |U| is larger. As a side effect
you get fewer generators.

One can extend this approach to abelian groups  U:  Here  we  can
take  the subgroup of Aut(U), which fixes the cycle structures of
all elements in U as guessed group. Certainly it has  to  contain
the normalizer induced subgroup; usually it is much smaller. When
using the permutation action of Aut(U) on U, this subgroup can be
computed  as  a  set  stabilizer.  Another backtrack routine then
searches for the actual normalizer induced subgroup. It turns out
that  the  guessed group usually is in very good approximation to
the group we want, so we don't have  to  worry  about  this  last
backtrack.  I reckon it might be even worth to extend it to other
relatively small groups, however then the automorphism  group  is
not that easy to get.

I  have  implemented  this approach for elementary abelian groups
(it would be not too hard to extend it  to  the  general  abelian
case,  but I just needed elementary abelian). In computations for
my thesis, I usually have to  compute  normalizers  of  (Z_p)^d  in
Z_p \wr  S_n  (n>=d).  Even the faster normalizer choked on these
problems for higher (p,n),while the 'automorphism guessing' works
quite well.  If there is interest for it, I can put a version for
GAP 3.4 on our ftp server.

Alexander



From helmut.geyer@iwr.uni-heidelberg.de Fri Jan  5 13:56:15 1996
Date:           Fri, 05 Jan 96 13:56:15 +0100
From:           "Helmut Geyer" <helmut.geyer@iwr.uni-heidelberg.de>
Subject:        FieldPolynomialRingOps.StandardAssociate bug in 3r4p3

FieldPolynomialRingOps.StandardAssociate still has the same bug as
3r4p2 when called with the 0 polynomial:

gap> x:=X(Rationals);
X(Rationals)
gap> StandardAssociate(0*x);
Error, List Element: <position> must be a positive integer at
return f * f.coefficients[Length( f.coefficients )] ^ (-1 * 1) ... in
R.operations.StandardAssociate( R, r ) called from
StandardAssociate( 0 * x ) called from
main loop
brk> `

A fix for 3r4p2 was available, but has been left out:
--- polyfld.g  Mon Jul 31 13:54:20 1995
+++ polyfld.g.orig   Mon Jul 31 13:53:09 1995
@@ -58,9 +58,6 @@
 #F  FieldPolynomialRingOps.StandardAssociate( <R>, <f> )  . . . .  normed pol
 ##
 FieldPolynomialRingOps.StandardAssociate := function( R, f )
-    if Length(f.coefficients)=0 then
-      return Zero(R);
-    fi;
     return f * f.coefficients[ Length( f.coefficients ) ]^-1;
 end;


        Helmut Geyer



From eamonn.obrien@maths.anu.edu.au Mon Jan  8 10:43:00 1996
Date:           Mon, 08 Jan 96 10:43:00 +0100 (MET)
From:           "Eamonn O'Brien" <eamonn.obrien@maths.anu.edu.au>
Subject:        Group tables by Thomas and Wood

Erhard Aichinger asks

>I am using
>   TwoGroup (32, 6)
>to get the 6th group of order 32. Do you
>know whether the numbering of groups in the twogroup-package is
>identical to the numbering in the book
>  Thomas, A.D., and  Wood G.V.,  Group Tables, Shiva Publishing Ltd. ?

In short, there is *no* connection at all between the
numbering employed in the TwoGroups library and that
of Thomas and Wood.  If you want information on the
numbering scheme used (and its basis), then look at the
references listed in the GAP manual for the library.

However, if you type in a Thomas and Wood presentation,
then the GAP function 'GroupId' would allow you
to find its number in the TwoGroups library.
>From the GAP manual:

>For certain  small groups 'GroupId' returns  a record  which will
>identify the isomorphism type of <G>  with respect to certain
>classifications.

For p-groups, 'GroupId' uses the p-group isomorphism and standard
presentation function supplied via the package 'anupq'.


Eamonn O'Brien
-------------------------------------

Lehrstuhl D fuer Mathematik, RWTH; E-mail: obrien@math.rwth-aachen.de



From joachim.neubueser@math.rwth-aachen.de Mon Jan 15 19:08:56 1996
Date:           Mon, 15 Jan 96 19:08:56 +1553
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Re: Thanks

Dear Dr. Gurican,

In your  last  letter  you  had asked  what  formal  requirements your
students work would  have  to fulfill in   order to  be  submitted for
possible inclusion with GAP. There are three obvious ones:

1. There should be a  consistent and complete description (in English)
of  the theoretical background.    As  in papers,  otherwise published
material  can be quoted, but  for readability at least all definitions
should be given and  proofs of any claims  that cannot be found in the
literature.

2. There  should be a clear description   of the implemented functions
and  their use that is as  similar as possible  in style and format to
the descriptions in the GAP manual. That is, if the functions would be
incorporated  into GAP manual then  these descriptions should fit into
the manual.

3. There  should  be clearly written  GAP code  with well written  and
helpful comments on what the function is doing.

All this should be  in a reasonably  final  form. It  may be that  the
referee might  have suggestions for  improvement, but (s)he should not
have the task to find a path through wilderness.

What I have so far got from you was not yet in such  a form but rather
represented  sketches of the  state of the  development of  ideas at a
certain  time. Please do not  be  offended that much  to  my regret  I
simply do not have the  time to work my way  through that and to write
long letters of recommendations (nor can I  ask a referee to do that).
I have sometimes  a dozen letters  per day to  answer and  of course I
have my normal  teaching   load and  my own   students.   It is   most
certainly not  snobism or bad  will,  but simply lack  of time  that I
cannot really help students    in other places through  their  initial
problems,  but  I  will  try  to help  with  getting   information and
eventually finding a referee.

Wishing further good  progress  with the permutational  products, with
kind regards                  Joachim Neubueser



From volkmar.felsch@math.rwth-aachen.de Tue Jan 16 08:14:28 1996
Date:           Tue, 16 Jan 96 08:14:28 +0100
From:           "Volkmar Felsch" <Volkmar.Felsch@Math.RWTH-Aachen.DE>
Subject:        Non up-to-date examples in the manual

The purpose of this message is to warn you of the fact that there
are some non up-to-date examples in the manual chapters on "Algebraic
extensions of fields" and on the code theory package "Guava".

At the end of the GAP manual section 1.1 you will find the following
claim.

>  The examples of GAP sessions given in any particular chapter of
>  this manual have been run in one continuous session, starting with
>  the two commands
>
>     SizeScreen( [ 72, ] );
>     LogTo( "erg.log" );
>
>  which are used to set the line length to 72 and to save a listing
>  of the session on some file. If you choose any chapter and rerun
>  its examples in the given order, you should be able to reproduce
>  our results except of a few lines of output which we have edited
>  a little bit with respect to blanks or line breaks in order to
>  improve the readability. However, as soon as random processes are
>  involved, you may get different results if you extract single
>  examples and run them separately.

Our experience shows that any correction, improvement, or extension
of GAP may affect several examples in several chapters of the
manual. Therefore it is necessary to rerun and to update  a l l
examples whenever we prepare a new GAP release. In particular, we
had to do this for the recent patch 3.4.3 and, in fact, we thought
that we had run all the checks when we released the patch.

However, now it turned out that by some accident we have missed so
far to apply the procedure to the three manual chapters which were
new in the patches 3.4.1 or 3.4.2. The consequence is that some non
up-to-date (or even wrong) examples have survived in two chapters
of the current manual. Therefore we offer updated versions of these
two chapters.

Chapter 16. "Algebraic extensions of fields"

   There are only a few changes, and they are harmless. The most
   essential alterations are the correction of a wrong result and
   the replacement of an example by a more appropriate one because
   the original one took several CPU hours.

Chapter 60. "Guava"

   There are several modifications in the examples of the updated
   version, but most of these changes are just due to the fact that
   the output format of certain GUAVA functions has slightly changed
   since they were first implemented in GAP. We also have updated
   the calls of two functions whose names have changed. Moreover, we
   have fixed a few examples that were not quite correct, and we
   have inserted the call of the RequirePackage function which is
   needed at the beginning of the first example.

In case that you want to reprint these two manual chapters, you may
obtain the updated files  algext.tex  and  guava.tex  via anonymous
ftp from

    ftp.math.rwth-aachen.de:/pub/incoming/

We would like to apologize for any inconvenience caused by the fact
that we missed to fix these files in time.

Volkmar Felsch (Aachen)



From jasper@win.tue.nl Tue Jan 16 09:25:33 1996
Date:           Tue, 16 Jan 96 09:25:33 +0100
From:           "Jasper Cramwinckel" <jasper@win.tue.nl>
Subject:        Re: Non up-to-date examples in the manual

Dear Volkmar,

I read your submission to the GAP-forum. You wrote that the Guava chapter
of the manual was outdated and that you fixed it. Frank Celler and I
found out that in Gap 3.4.2, an older version of the Guava manual was
included. I told Frank Celler what the newest version of the manual was,
which he would include in the newest release of GAP. Did you use this
version of the Guava chapter, or did you make all the corrections you
mentioned in the forum by hand? In the last case, I think it would be
better to distribute the newest version of the chapter, rather than the
"updated outdated" one.

Jasper Cramwinckel



From alexander.hulpke@math.rwth-aachen.de Tue Jan 16 10:04:28 1996
Date:           Tue, 16 Jan 96 10:04:28 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: FieldPolynomialRingOps.StandardAssociate bug in 3r4p3

Dear GAP-Forum,

Helmut Geyer wrote:

> FieldPolynomialRingOps.StandardAssociate still has the same bug as
> 3r4p2 when called with the 0 polynomial:
>
> gap> x:=X(Rationals);
> X(Rationals)
> gap> StandardAssociate(0*x);
> Error, List Element: <position> must be a positive integer at

Thanks for bringing this to our attention. I can't trace back why this
happened, but obviously this patch somehow fell off the table when preparing
version 3.4.3. We apologize for this error (and hope we will be more
attentive next time).

Alexander Hulpke



From frank.celler@math.rwth-aachen.de Thu Jan 18 11:49:00 1996
Date:           Thu, 18 Jan 96 11:49:00 +0100 (MET)
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        mail accidents

Dear Forum,

several times you have been bothered by messages coming to the GAP Forum
that didn't belong there.  They were essentially caused in two ways:

1) unsubscribe messages were sent to the Forum instead of being sent
   to Miles, the software that maintains the GAP Forum,

2) somebody wanting to write to an author of a letter to the GAP Forum
   used the reply function of his/her mailer. However, such a letter then
   went to the Forum.

In order to protect you from such unwanted mail, we have decided to
install a safeguard.

1) Any mail sent to the Forum beginning with "subscribe" or "unsubscribe"
   will be rejected.  The author of such a mail will automatically get a
   letter in which he/she is told to send this message to

       Miles@Math.RWTH-Aachen.DE

2) The first line of any reply to the Forum must contain at least one of the
   words "GAP" or "forum" (case insensitive).  So for instance you could
   start by saying "Dear GAP Forum", "Dear Forum Members" or the like.
   If you send a message to the GAP Forum using the reply function without
   using one of the keywords in the first line,  the message will be rejected
   and a you will get a warning repeating the advice given here.

If you don't want to use the above keywords in answering to the GAP
Forum, instead of using the reply function send your mail to

       GAP-Forum@Math.RWTH-Aachen.DE.

If you want to write to the author of a Forum message, please use the
address given in the "From:" field of the message.

It is clear that this safeguard cannot catch all unwanted replies,
but it should catch at least the obvious ones.

with kind regards
  Frank Celler and Joachim Neubueser



From alexander.hulpke@math.rwth-aachen.de Thu Jan 18 13:17:12 1996
Date:           Thu, 18 Jan 96 13:17:12 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Problem with the Library file 'galois.g'

Dear GAP-Forum,

When trying to be very clever in allowing to change the range of the
transitive groups library, I shot myself in the foot. So far, calling
'Galois' directly issues an error in version 3.4.3:

> gap> Galois(x^3+13);
> Error, Variable: 'TRANSDEGREES' must have a value

There are three possible ways to avoid this:

1. Call 'ReadGrp("trans")' before calling 'Galois'.

2. Add a line 'TRANSDEGREES:=15' to your .gaprc file. (I did this myself
long ago, so I did not find the error in the first place... Now I know
that I should not have done this. Sorry.)

3. change the file 'galois.g'. The paragraph starting in line 570 ought to
be:

#############################################################################
##
#V  TRANSHAPEFREQS . . . . . . . . . . shape frequencies in transitive groups
##
if not IsBound(TRANSHAPEFREQS) then
  ReadGrp("trans");
  TRANSHAPEFREQS:=List([1..TRANSDEGREES],i->[]);
fi;

I hope this does not imply problems for any user.

Alexander Hulpke
(who will not again fool around with the automatic library reading)



From nordbeem@caa.mrs.umn.edu Wed Jan 24 11:24:53 1996
Date:           Wed, 24 Jan 96 11:24:53 -0500
From:           "Eric Nordberg " <nordbeem@caa.mrs.umn.edu>
Subject:        gap and group algebras

HI, I am trying to do computations in group algrabras.  Mostly, using
groups such as s3 (permuations in three places.)  Is there any decent
way to define an algebra of this sort, seeing as how the permuations do not
form a ring.  If not, is there any way to define addition for
permuations, so that I can psuedo form my own algebra?  If neither of
these work, are there any other suggestions with gap?
thanks,
              Eric Nordberg



From joachim.neubueser@math.rwth-aachen.de Thu Jan 25 14:08:47 1996
Date:           Thu, 25 Jan 96 14:08:47 +1553
From:           "Joachim Neubueser" <Joachim.Neubueser@Math.RWTH-Aachen.DE>
Subject:        Contents of messages to GAP-Forum

Dear GAP-Forum members,

We have  been asked several times, if  announcements could  be sent to
the GAP-Forum, that do  not  relate directly  to GAP  but might be  of
interest to some  of the members of the  Forum.   Quite recently there
were two  such cases, one was the  advertisement of  a position in the
mathematics department in  Auckland, where among the expertise  wanted
group and representation theory as   well as computational  experience
were  mentioned.  The  other was   the  announcement  of a  meeting on
crystallographic and related groups in Belgium.

In both  cases (and each time with  some personal regret) I have asked
not to send  this advertisement to the  GAP-Forum.  The reason is that
nowadays for  all  such  advertisements and announcements    there are
better places and  that we want  to  keep the  GAP-Forum restricted to
matters that  really relate  to GAP.  (That  is, only  if a  person is
wanted to   help  working with GAP,   this  might be a  case   for the
GAP-Forum or if a meeting  on Computational Group Theory is  announced
in which likely GAP will be an issue, this might be another.)

I would like, however,  to direct your  attention with respect to such
announcements to the group-pub-forum maintained by Geoff Smith at Bath
and a WWW page there which do take and spread such information without
overwhelming  its members with too   much mail. (The two announcements
mentioned above both appeared in  the group-pub-forum). I recommend to
subscribe to  that   forum and for  your   convenience I append   some
information about it which I have copied from a  letter of Geoff Smith
in the group-pub-forum and the WWW page there.

With kind regards     Joachim Neubueser

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

To subscribe or unsubscribe to the mailing list

group-pub-forum@maths.bath.ac.uk

or to notify a temporary or permanent  change your email address, send
an email request to

group-landlord@maths.bath.ac.uk

---------------------------------------------------------------------
Folk in the Forum

You may  also wish to  appear in Folk  in the Forum  in which case you
need to send a request to group-landlord@maths.bath.ac.uk containing

       Your name
       Your home institution (if any)
       The URL of your home page (if possible)

A link from Group-Pub-Forum-on-the-Web to your home  page will then be
set up. If you do not have a home page, then a less clean mechanism is
for you to send a short file containing information  as to how you may
be contacted. This might include your name, work and/or home addresses
and telephone  numbers, fax numbers, email addresses  and  so on. This
file  will be stored  for display by  the forum web pages. These files
will look better if they are typeset in Tex,  Latex or Postscript, but
plain text will suffice.


---------------------------------------------------------------------
Internet surfing opportunity:

Subscribers  to group-pub-forum may be  interested  to learn that  the
forum now has its own page on the World Wide  Web. The address of this
page on WWW (jargon = its URL) is:

http://www.bath.ac.uk/~masgcs/gpf.html

>From this   page   there are links     to information on   forthcoming
conferences  and also to a (currently  empty) list of job and research
opportunities for  group  theorists. Galway and  Canberra already have
their conference information available there.

Information   on these topics   which is posted to  the  forum will be
archived into the appropriate WWW page so that Web  users will be able
to  read it.  Setting up  such  information on  the  Web yourself will
enable us to put  in a  link  from group-pub-forum-on-the-Web  to your
page. That way, when the  information  is updated (e.g `conference  is
cancelled, organizers  arrested' or  `mathematics department closed by
sanitary inspectors') then this  new information is automatically made
available to Web users.  Persons  wishing to do  this should learn how
to use  the (easy) language  HTML.  Consult   your local webmaster  or
surfing expert.

In      the   near  future    links        will  be  set   up     from
group-pub-forum-on-the-Web  to all  the good places   -- so  that, for
example,     you can tell     your   research students   to  scour  MR
electronically.

Geoff Smith
(URL:  http://www.bath.ac.uk/~masgcs/home.html)

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



From wdj@sma.usna.navy.mil Wed Jan 24 14:34:44 1996
Date:           Wed, 24 Jan 96 14:34:44 -0500
From:           "W. David Joyner" <wdj@sma.usna.navy.mil>
Subject:        Cayley graphs

Dear Forum:
 I have two questions:

1. Given elements g1,...,gm in the symmetric group Sn on n letters,
let G:=Group(g1,...,gm). Can one use GRAPE to construct the Cayley
graph for G relative to the g1,...,gm? (Ie, the vertices are labeled
by the elements of G and two vertices are connected by an edge (I
don't care about directions) if and only if one is g.i times the
other for some 1 <= i <= m.)

2. I have tried using the share package AbStab.g to ``solve'' the
masterball, a Rubik's cube-like puzzle. (AbStab.g is a GAP share
package.) I've implemented the masterball in MAPLE for the
purpose of testing out moves, etc. The problem is that sometimes
the AbStab.g ``solution'' works in MAPLE and sometimes it doesn't.
My question: Has anyone tested AbStab.g out on the Rubik's cube
and checked their result on the cube or a computer simulation of the
cube? Basically, I'm wondering if the problem is with me, GAP, or MAPLE.
Also, I'm interested in the mathematics behind the AbStab.g
package, so any references would be appreciated.


                                       - David Joyner, wdj@sma.usna.navy.mil



From thomas.breuer@math.rwth-aachen.de Thu Jan 25 19:22:00 1996
Date:           Thu, 25 Jan 96 19:22:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        Re: gap and group algebras

Dear GAP-Forum,

Eric Nordberg asked the following questions.

> HI, I am trying to do computations in group algrabras.  Mostly, using
> groups such as s3 (permuations in three places.)  Is there any decent
> way to define an algebra of this sort, seeing as how the permuations do not
> form a ring.  If not, is there any way to define addition for
> permuations, so that I can psuedo form my own algebra?  If neither of
> these work, are there any other suggestions with gap?

The proper way to define group algebras in GAP is to put the group
elements into records, and to define addition, subtraction, multiplication,
powering and so on for these records.
It depends on the sort of computations one has in mind how many facilities
one really needs to provide for group algebra elements and group algebras.

About two years ago Philip Osterlund wrote some nice GAP code for computing
in group algebras.
If he does not object then I will put this as a package into the 'incoming'
directory on our server, and then inform you about this.

Kind regards
Thomas Breuer



From leonard@qmw.ac.uk Fri Jan 26 15:42:23 1996
Date:           Fri, 26 Jan 96 15:42:23 +0000 (GMT)
From:           "Leonard Soicher" <leonard@qmw.ac.uk>
Subject:        Cayley graphs in GRAPE

Dear GAP-forum,

Many people are using GRAPE to study Cayley graphs, and I am often
asked how to construct Cayley graphs in GRAPE.  My answer is "use the
wonderfully general  Graph  function in GRAPE".  Everyone who uses
GRAPE should learn this function well, as it's usually the one to use
when the question is "how do I construct an XXX-type graph?".

So below, I enclose an example for the construction of a Cayley graph.

Suppose  G  is a group, and  gens  a generating list of elements of
G.  Then to construct in  caygraph  the Cayley graph for  G  such that
x  is joined to  y  iff there is a  g  in  gens with  y=g*x,
the following statement will do:

caygraph := Graph(G, Elements(G), OnRight,
                function(x,y) return ForAny(gens,g->y=g*x); end, true);

Note that  caygraph.group  comes from the right regular action of
G  as a group of automorphisms of the Cayley graph constructed.  It is
a good idea to use the statement:

StabChain(caygraph.group,rec(size:=caygraph.order));

to make efficiently a stabilizer chain for caygraph.group of known
order (= the number of vertices of  caygraph).

Finally, if  gens  is not closed under inversion, but you want the
underlying undirected graph of  caygraph,  then set:

caygraph:=UnderlyingGraph(caygraph);


Hope this is useful,

                     Leonard Soicher.

P.S. As always, I want to hear about applications of GRAPE, especially
publications referencing GRAPE.  The reference for GRAPE is:

L.H.~Soicher, {\sf GRAPE}: a system for computing with graphs and
groups, in {\it Groups and Computation}, L.~Finkelstein and
W.M.~Kantor, eds., DIMACS Series in Discrete Mathematics and
Theoretical Computer Science {\bf 11}, A.M.S., 1993, pp.~287--291.

GRAPE is freely available for non-commercial, non-military use.



From heiko.theissen@math.rwth-aachen.de Wed Jan 31 11:11:00 1996
Date:           Wed, 31 Jan 96 11:11:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: AbStab.g

Dear GAP forum,
Dear David Joyner,

you have asked questions concerning the  construction of Cayley graphs
with  GRAPE and concerning  the `AbStab.g'  package  in the GAP forum.
Leonard Soicher has  already answered the GRAPE part  in the GAP forum
and with this message I want to inform you about the `AbStab.g' issue.

The `AbStab.g' file was put in the `pub/incoming' directory on our ftp
server by  Philip Osterlund.  We   encourage authors of such files  to
make their GAP-related  work available  by  putting it on our  server,
however we do not provide any service for such  files.  That is, we do
not check the programs or data in this  directory and hence in general
we cannot offer help if users have difficulties with them.  All we can
do in such cases is  inform the author and  ask him/her to answer  the
request concerning his/her file.

I have in the meantime  sent a message to  Philip Osterlund and  asked
him if  he  could  provide    you  with some information    about  the
mathematics behind his algorithm.    His answer should go directly  to
the GAP forum.

I have used  the `AbStab.g' library  quite a bit for  Rubik's Cube.  I
never encountered a problem at all.  Could it be that the problems you
have  with ``solutions'' not working in  Maple arise because the model
you use in Maple is slightly different from the one used in GAP (e.g.,
different order of generators)?   Note that the ``solutions'' found by
`AbStab.g' are still not optimal.   In the case  of Rubik's Cube, they
are usually about an order of magnitude too long.

By the way: While trying to  play with `AbStab.g'  I have noticed that
the function  `MakeAbStabChain' runs into an  error in GAP V3R4P3, but
succeeds  in GAP V3R4P2.   The reason is that  third update included a
modification of the function `List'.  In GAP V3R4P2 the first argument
could have holes (even though the manual forbids this), so e.g.

  List( [, 1 ], x -> x ^ 2 )  returned  [ 1 ]

while in GAP V3R4P3 this now results in an error.  I suppose that your
experiments with `AbStab.g' were done in GAP  V3R4P2 (or earlier).  Is
this right?

The  following  change fixes `AbStab.g'   enough so that  one  can use
`MakeAbStabChain'  and `Shrink' in GAP  V3R4P3  (but there maybe other
places in `AbStab.g' that need to be adapted likewise).

--- AbStab.g.orig   Fri Oct 28 21:34:03 1994
+++ AbStab.g    Wed Jan 31 10:41:19 1996
@@ -210,8 +210,10 @@
     lt:=LeftSchreier(arg);
     alt:= lt.ASchreier;
     lt := lt.Schreier;
-    rt:=List(lt,x->x^-1);
-    art:=List(alt,x->x^-1);
+    # rt:=List(lt,x->x^-1);
+    # art:=List(alt,x->x^-1);
+    rt:=[]; for x in lt do Add( rt, x^-1 ); od;
+    art:=[]; for x in alt do Add( art, x^-1 ); od;
     for g in G.generators do
        i:=Position(G.generators, g);
        ag := G.abstractGenerators[i];

Sorry I cannot be of more help at the moment.

Heiko Thei{\ss}en and Martin Sch\"onert



From wdj@sma.usna.navy.mil Wed Jan 31 10:55:00 1996
Date:           Wed, 31 Jan 96 10:55:00 -0500
From:           "W. David Joyner" <wdj@sma.usna.navy.mil>
Subject:        Re: AbStab.g

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 53

Dear Forum and Heiko Thei{\ss}en and Martin Sch\"onert:

 Thanks for your response.

You said:

> I have used  the `AbStab.g' library  quite a bit for  Rubik's Cube.  I
> never encountered a problem at all.  Could it be that the problems you
> have  with ``solutions'' not working in  Maple arise because the model
> you use in Maple is slightly different from the one used in GAP (e.g.,
> different order of generators)?   Note that the ``solutions'' found by

I don't believe so. I carefully determined all the generators used by abstab.g
in terms of my generators.

> `AbStab.g' are still not optimal.   In the case  of Rubik's Cube, they
> are usually about an order of magnitude too long.

I'll explain why I think abstab.g has an error. I used GAP and abstab.g
for the group of the masterball, which has size ~4.3x10^26. I usually
can eventually get the masterball into one of two ``nearly solved''
positions: one requiring a 2-cycle and the other requiring a 3-cycle.
Shrink in abstab.g gives a ~90 move long solution to the 3-cycle position
which works. I checked this on my maple implementation and by hand.
Shrink gives a slightly longer solution for the 2-cycle. It does
not work by my maple computer implementation nor by hand. Moreover,
the ``word'' returned by Shrink is *not* equal to the ``word'' returned
by FactorPermGroupElement. This makes me suspicious.

>
> By the way: While trying to  play with `AbStab.g'  I have noticed that
> the function  `MakeAbStabChain' runs into an  error in GAP V3R4P3, but
> succeeds  in GAP V3R4P2.   The reason is that  third update included a
> modification of the function `List'.  In GAP V3R4P2 the first argument
> could have holes (even though the manual forbids this), so e.g.
>
>   List( [, 1 ], x -> x ^ 2 )  returned  [ 1 ]
>
> while in GAP V3R4P3 this now results in an error.  I suppose that your
> experiments with `AbStab.g' were done in GAP  V3R4P2 (or earlier).  Is
> this right?

I used gap3r4p2 at work and I used gap3r4p3 with the 3r4p2 library
at home with no errors of this kind.

Attached by a sun mailtool attachment is a history of a gap session
which produces the above described problem. Also included is a .g
file containing the group-theoretical data for the masterball group,
for anyone interested. I'm enclosing this because, based on this session,
I conjecture that Shrink in abstab.g has a bug. However, I would be
happy to hear of some other explanation for the problem.

                                            - David Joyner
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: bug.txt
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 86


51 math65:/home/math6/wdj> gap

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

                            For help enter: ?<return>
gap> LogTo("/home/math6/wdj/gap/games/bug.log");
gap> Read("/home/math6/wdj/gap/games/grpdata.g");
gap> Read("/home/math6/wdj/gap/new/AbStab.g");
The record 'descriptions' contains brief descriptions of the functions
in this file.
Functions of importance: MakeAbStabChain, FactorPermGroupElement, Shrink
gap> gen:=Set([f1,f2,f3,f4,r1,r2,r3,r4]);
[ (25,26,27,28,29,30,31,32), (17,18,19,20,21,22,23,24),
  ( 9,10,11,12,13,14,15,16), ( 4,31)( 5,30)( 6,29)( 7,28)(12,23)(13,22)(14,21)
    (15,20), ( 3,30)( 4,29)( 5,28)( 6,27)(11,22)(12,21)(13,20)(14,19),
  ( 2,29)( 3,28)( 4,27)( 5,26)(10,21)(11,22)(12,23)(13,24), (1,2,3,4,5,6,7,8),
  ( 1,28)( 2,27)( 3,26)( 4,25)( 9,20)(10,19)(11,18)(12,17) ]
gap> G:=MinGenSet(gen);
Group( (25,26,27,28,29,30,31,32), (17,18,19,20,21,22,23,24), ( 9,10,11,12,13,
 14,15,16), ( 4,31)( 5,30)( 6,29)( 7,28)(12,23)(13,22)(14,21)(15,20), ( 3,30)
( 4,29)( 5,28)( 6,27)(11,22)(12,21)(13,20)(14,19), ( 2,29)( 3,28)( 4,27)
( 5,26)(10,21)(11,22)(12,23)(13,24), (1,2,3,4,5,6,7,8) )
gap> 2_cycle:=(1,2);
(1,2)
gap> cycle2a:=FactorPermGroupElement(G,2_cycle);
g1^2*g5*g7*g5^-1*g1*g5*g7^-1*g5^-1*g1^-1*g5*g7*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1^-\
1*g5*g7*g5^-1*g1^3*g5*g7^-1*g5^-1*g1*g5*g7*g5^-1*g1^-1*g5*g7^-1*g5^-1*g1^-3*g5\
*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-\
3*g5^-1*g1^-1*g5*g7*g5^-1*g1^-2*g5*g7*g5^-1*g1^3*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1\
*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-1*g1^-1*g5*g7*g5^-1*\
g1^2*g5*g7^-1*g5^-1*g1*g5*g7*g5^-1*g1^-1*g5*g7^-1*g5^-1*g1^-3*g5*g7*g5^-1*g1^2\
*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*\
g5*g7*g5^-1*g1^-1*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g\
7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-1*g1^-2*g5*g7*g5^-1*g1^3*g5*g7^-1*\
g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-\
1*g1^-1*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1*g5*g7*g5^-1*g1^-1*g5*g7^-1*g5^-1*g1\
^-3*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g\
5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-1*g1^-1*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1^-2*g5\
*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-1*g1^-2*g5*g7*\
g5^-1*g1^3*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5\
^-1*g1^-1*g5*g7*g5^-1*g1^-1*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1*g5*g7*g5^-1*g1^\
-1*g5*g7^-1*g5^-1*g1^-3*g5*g7*g5^-1*g1^2*g5*g7^-1*g5^-1*g1^-2*g5*g7^-1*g5^-1*g\
1*g5*g7^3*g5^-1*g1*g5*g7^-3*g5^-1*g1^-1*g5*g7*g5^-1*g1^2*g5*g7*g5^-1*g1*g5*g7^\
-1*g5^-1*g1^-1*g5*g7*g5^-1*g1^-3*g5*g7^-1*g5^-1*g1*g5*g7*g5^-1*g1^2*g5*g7^-1*g\
5^-1*g1*g5*g7*g5^-1*g1^-1*g5*g7^-1*g5^-1*g1^-2
gap> cycle2b:=Shrink(G,cycle2a);
g1^-2*g5^-1*g1*g4^-1*g1*g4^-1*g1^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-3*g5^-1*g1^-1*g\
5^-1*g7*g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7*g5^-1*\
g1^-1*g5^-1*g7^-1*g5^-1*g1^-4*g5^-1*g7*g5^-1*g1*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^\
-2*g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7^4*g5^-1*g1\
*g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^3*g\
5^-1*g1*g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1
gap> cycle2a=cycle2b;
false
gap> cycle2c:=Shrink(G,2_cycle);
g1^-2*g5^-1*g1*g4^-1*g1*g4^-1*g1^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-3*g5^-1*g1^-1*g\
5^-1*g7*g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7*g5^-1*\
g1^-1*g5^-1*g7^-1*g5^-1*g1^-4*g5^-1*g7*g5^-1*g1*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^\
-2*g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7^4*g5^-1*g1\
*g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^3*g\
5^-1*g1*g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1
gap> cycle2b=cycle2c;
true
gap> quit;
258.33u 75.28s 33:19.81 16.6%
52 math65:/home/math6/wdj>
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: grpdata.g
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 14

r1 := (1, 2, 3, 4, 5, 6, 7, 8);
r2 := (9, 10, 11, 12, 13, 14, 15, 16);
r3 := (17, 18, 19, 20, 21, 22, 23, 24);
r4 := (25, 26, 27, 28, 29, 30, 31, 32);
f1 := (1, 28)(2, 27)(3, 26)(4, 25)(9, 20)(10, 19)(11, 18)(12, 17);
f2 := (2, 29)(3, 28)(4, 27)(5, 26)(10, 21)(11, 22)(12, 23)(13, 24);
f3 := (3, 30)(4, 29)(5, 28)(6, 27)(11, 22)(12, 21)(13, 20)(14, 19);
f4 := (4, 31)(5, 30)(6, 29)(7, 28)(12, 23)(13, 22)(14, 21)(15, 20);
f5 := (5, 32)(6, 31)(7, 30)(8, 29)(13, 24)(14, 23)(15, 22)(16, 21);
f6 := (6, 25)(7, 32)(8, 31)(1, 30)(14, 17)(15, 24)(16, 23)(9, 22);
f7 := (7, 26)(8, 25)(1, 32)(2, 31)(15, 18)(16, 17)(9, 24)(10, 23);
f8 := (8, 27)(1, 26)(2, 25)(3, 32)(16, 19)(9, 18)(10, 17)(11, 24);
order_of_group := 437763136697395052544000000;
geners := Set([r1,r2,r3,r4,f1,f2,f3,f4,f5,f6,f7,f8]);



From mejohnsn@netcom.com Thu Feb  1 00:18:40 1996
Date:           Thu, 01 Feb 96 00:18:40 -0800
From:           "Matthew Johnson" <mejohnsn@netcom.com>
Subject:        Help with GAP Bug?

Dear Fellow GAP users:
I have ported GAP to Windows NT, which port is not quite ready for returning
to Martin to be included in his revision control system.  However, the
following bug also appears under the Mac and NextStep builds of the same
version of the kernel and relevant libraries.  The bug is largely explained
in the comments of the code, but I will say here that removing the call to
IsPrimeInt() makes the problem go away; I will also say that the crash
may appear with a quite different error message if any other code is
added to the loop or if run under the Mac or NextStep versions:  under
NextStep (a GUI-enhanced MACH UNIX) I usually get a "Segmentation Fault",
under NT I usually get a "STack Overflow" (but occasionally as in
NExtStep), under MacOS 7.5 I get Segmentation Fault.

Thus I am pretty sure that the problem is not in the NT port.  The NT
port does have the advantage that NT has at least _some_ debugging tools,
although they are not that helpful with an interpreted program, like a
GAP program.

One peculiarity that may have something to do with the NT port: following the
DOS tradition, STDERR is unbuffered, with a separate handle from STDOUT even
when both point to the same physical device.  So I am not sure that the
comment below about the error output taking place during output of the final
fibonacci number is really significant.

Matthew Johnson
Firepower Systems
Menlo Park California

# fibonacci numbers
# This program computes Fibonacci numbers and culls the same for primes.

# With the call to IsPrimeInt, this program crashes on the 2971st Fibonacci number
# All I have been able to find with my primitive tools is that the function call stack
# is filled with repetitive calls to a EvFunccall (apparently to evaluate IsPrimeInt itself)
# after which the exception is generated on a call to NewBag()
# Oh yes, running with the '-g' option shows this crash occurs during/after garbage
# collection, which in turn takes place before the last Fibonacci number has been
# entirely printed out.

# Use the following for recursive computation of F(n)
i := 3;

g := 1;
fib := [1, 1, 2];
while i<2972 do         # On NT crashes on 2971
        j := 1;
        nfib := fib[i] + fib[i-1];
        Add(fib, nfib );
        Print("\nfib[",i+1,"] = ", fib[i+1]);
        test := IsPrimeInt(nfib);          # the failure appears to be here
        if test = true then
                Print("\n\tIsPrimeInt = TRUE");
        fi;
        i := i+1;
od;



From martin.schoenert@math.rwth-aachen.de Fri Feb  2 12:46:00 1996
Date:           Fri, 02 Feb 96 12:46:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Re: AbStab.g

W. David Joyner wrote in his e-mail message of 1996/01/31

    I'll explain why I think abstab.g has an error. I used GAP and abstab.g
    for the group of the masterball, which has size ~4.3x10^26. I usually
    can eventually get the masterball into one of two ``nearly solved''
    positions: one requiring a 2-cycle and the other requiring a 3-cycle.
    Shrink in abstab.g gives a ~90 move long solution to the 3-cycle position
    which works. I checked this on my maple implementation and by hand.
    Shrink gives a slightly longer solution for the 2-cycle. It does
    not work by my maple computer implementation nor by hand. Moreover,
    the ``word'' returned by Shrink is *not* equal to the ``word'' returned
    by FactorPermGroupElement. This makes me suspicious.

Well there are many words representing a particular element of your
group.  'FactorPermGroupElement' simply finds one such word.  'Shrink'
takes such a word, and then tries to find a shorter word representing the
same element.  Thus there is no reason that 'FactorPermGroupElement' and
'Shrink' should return the same word.  In fact one would usually hope
that 'Shrink' returns a different word.

He continued with a log of his GAP run

    gap> LogTo("/home/math6/wdj/gap/games/bug.log");
    gap> Read("/home/math6/wdj/gap/games/grpdata.g");
    gap> Read("/home/math6/wdj/gap/new/AbStab.g");
    The record 'descriptions' contains brief descriptions of the functions
    in this file.
    Functions of importance: MakeAbStabChain, FactorPermGroupElement, Shrink
    gap> gen:=Set([f1,f2,f3,f4,r1,r2,r3,r4]);
    [ (25,26,27,28,29,30,31,32), (17,18,19,20,21,22,23,24),
      ( 9,10,11,12,13,14,15,16),
      ( 4,31)( 5,30)( 6,29)( 7,28)(12,23)(13,22)(14,21)(15,20),
      ( 3,30)( 4,29)( 5,28)( 6,27)(11,22)(12,21)(13,20)(14,19),
      ( 2,29)( 3,28)( 4,27)( 5,26)(10,21)(11,22)(12,23)(13,24),
      (1,2,3,4,5,6,7,8),
      ( 1,28)( 2,27)( 3,26)( 4,25)( 9,20)(10,19)(11,18)(12,17) ]
    gap> G:=MinGenSet(gen);
    Group( (25,26,27,28,29,30,31,32), (17,18,19,20,21,22,23,24),
    ( 9,10,11,12,13,14,15,16),
    ( 4,31)( 5,30)( 6,29)( 7,28)(12,23)(13,22)(14,21)(15,20),
    ( 3,30)( 4,29)( 5,28)( 6,27)(11,22)(12,21)(13,20)(14,19),
    ( 2,29)( 3,28)( 4,27)( 5,26)(10,21)(11,22)(12,23)(13,24),
    (1,2,3,4,5,6,7,8) )
    gap> 2_cycle:=(1,2);
    (1,2)
    gap> cycle2a:=FactorPermGroupElement(G,2_cycle);
    <<word of length 409>>
    gap> cycle2b:=Shrink(G,cycle2a);
    <<word of length 107>>
    gap> cycle2a=cycle2b;
    false

As explained above this is ok.  It only shows that 'Shrink' was able to
find a shorter word.

    gap> cycle2c:=Shrink(G,2_cycle);
    <<word of length 107>>
    gap> cycle2b=cycle2c;
    true

Since 'Shrink' is deterministic this is also expected.

Both words are in fact correct, as can be seen by substituting the
generators back into the words

    gap> map( G, cycle2a );
    ( 1, 2)
    gap> map( G, cycle2b );
    ( 1, 2)

Maybe you are confused by the reording of the generators?  Since you said
'gen:=Set([f1,f2,f3,f4,r1,r2,r3,r4]);', GAP reorders the generators, so
'g1' corresponds to 'r4', 'g2' corresponds to 'r3', 'g3' corresponds to 'r2',
'g4' corresponds to 'f4', 'g5' corresponds to 'f3', 'g6' corresponds to 'f2',
and 'g7' corresponds to 'r1'.  I must confess that I don't understand
why you apply 'Set' to the generators list, why not simply take it as it is?

By the way.  The banner in the log says you are still running GAP 3.2.
The latest release is GAP 3.4.3.

Martin.

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



From margolis@bimacs.cs.biu.ac.il Sun Feb  4 16:58:59 1996
Date:           Sun, 04 Feb 96 16:58:59 +0200
From:           "Stuart M. Margolis" <margolis@bimacs.cs.biu.ac.il>
Subject:        New documentation

Hello:

I have a nicely bound version of the GAP documentation for version 3.2. I've
just obtained version 3.4 and have heard that the documentation is now over
1000 pages. In order to save some trees, is it possible to get an idea of
where the new material is and what chapters are worth printing out to
replace the former version.

Thanks,
Stuart W. Margolis



From martin.schoenert@math.rwth-aachen.de Mon Feb  5 10:22:00 1996
Date:           Mon, 05 Feb 96 10:22:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Workshop "Programming in GAP", Aachen, 1996/09/02-06

Dear GAP user,

we are planning a workshop

                           PROGRAMMING IN GAP

on GAP internals.

It will take place at Lehrstuhl D f"ur Mathematik, RWTH Aachen, Germany
from Mon, 2 Sep 1996 to Fri, 6 Sep 1996.

Its purpose is to provide interested users with the knowledge needed to
write GAP code that is efficient and integrates well with GAP's library.
It will be based on GAP 4, for which we plan to have a pre-release
available by then.

In five morning sessions we will present
* how (and why) GAP 4 organizes all objects into families and kinds,
* how one implements new kinds of elements in GAP 4 (e.g. sparse polynomials),
* how one implements new kinds of domains in GAP 4 (e.g. Lie algebras),
* how the GAP 4 kernel works and how one can add new internal functions,
* general tips and tricks how to use GAP 4 more efficiently.

The afternoons are reserved for
* demonstrations (e.g. of the GAP 4 compiler),
* exercises,
* informal discussions,
* talks and presentations by participants.

We expect participants to know GAP fairly well.  They should
* have written a fair bit of GAP 3 code,
* understand what a domain is in GAP 3,
* understand the purpose of operations records in GAP 3,
* probably have a good knowledge of C
  (at least if they want to understand how the kernel works),
* be willing to experiment with a pre-release of GAP 4
  (which will not be ready for a general release).

We must limit the number of participants to about 24.
Since we plan to start early Monday and to end late Friday,
we suggest that participants arrive Sunday and leave Saturday.

There is no fee for the workshop.  Participants should try to find
sources to cover their expenses, since we have only a very limited
amount of money to support participants.  We will try to help
participants to find reasonable and inexpensive accomodations.
In particular for participants that register early we can reserve
rooms in an IBIS hotel for DM 88/night, respectively DM 44/night
if two participants share such a room.

If you are interested or if you have suggestions, please write to
'GAP-Workshop@Math.RWTH-Aachen.DE'.

If you like to register, please send us your
* name:
* address:
* date of arrival:
* date of departure:
* kind of accomodation wanted:
  o bed and breakfast in private home,
  o single room in IBIS hotel @ DM 88/night,
  o shared room in IBIS hotel @ DM 44/night

Steve Linton and Martin Sch"onert.

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



From hoefling@mat.mathematik.uni-mainz.de Mon Feb  5 11:11:00 1996
Date:           Mon, 05 Feb 96 11:11:00 +0100
From:           "Burkhard Hoefling" <hoefling@mat.mathematik.uni-mainz.de>
Subject:        Re: problems with IsPrimeInt

Dear members of the Gap forum,

Mathew Johnson recently reported a problem with the IsPrimeInt
function, namely when testing whether the 2971th Fibonacci number is
a prime. As he reported, the problem is not system dependent (it
occurs on NextStep, Mac and his port to Windows NT).

The reason for Mathew's problem is simply a stack overflow, caused
by performing prime tests on large integers (large strong
pseudoprimes for the base 2, to be more precise). In so far, the GAP
manual is wrong in claiming that IsPrimeInt can test numbers with "a
few hundred digits".

To be more technical, IsPrimeInt performs various prime tests (see the
manual and the documentation in Integer.g for details), and the
2971th Fibonacci number is the first to pass all tests except for the
last one (to be more precise, it is a strong pseudoprime for the base
2). The last (probabilistic) prime test uses recursion to check
whether a number is a prime, and for the 2971th Fibonacci number,
this would require a recursion depth of about 2600, each call
requiring about 160 bytes on my Macintosh this should be system
dependent. Thus a (program) stack of about 400 Kilobytes would be
required for this calculation, while the usual stack size for GAP
seems to be about 64 Kilobytes.

There are two things which I would like to suggest:

- Since this phenomenon is very likely to occur also in other
contexts, GAP should check whether there is still enough processor
stack space when doing a (recursive) function call. This is, of
course, system dependent, and there should be a function in the
system dependent part of GAP which would then be called before every
function call. This, of course, does not resolve the problem with
IsPrimeInt, but it helps finding such problems.

- Perhaps it is useful to use another prime test. For example, as far
as I remember from my lectures on number theory, a reasonable
solution is to pick r positive integers n_1, ... n_r at
random, and to check whether the number p in question is a strong
pseudoprime with respect to all the numbers n_1, ... , n_r. Choosing
the number r large enough, the probability that p is not a prime can
be made as close to zero as desired. (But don't quote me on the
details ...).

I hope that I could be of some help.

Burkhard.




 > Dear Fellow GAP users:
> I have ported GAP to Windows NT, which port is not quite ready for returning
> to Martin to be included in his revision control system.  However, the
> following bug also appears under the Mac and NextStep builds of the same
> version of the kernel and relevant libraries.  The bug is largely explained
> in the comments of the code, but I will say here that removing the call to
> IsPrimeInt() makes the problem go away; I will also say that the crash
> may appear with a quite different error message if any other code is
> added to the loop or if run under the Mac or NextStep versions:  under
> NextStep (a GUI-enhanced MACH UNIX) I usually get a "Segmentation Fault",
> under NT I usually get a "STack Overflow" (but occasionally as in
> NExtStep), under MacOS 7.5 I get Segmentation Fault.
>
> Thus I am pretty sure that the problem is not in the NT port.  The NT
> port does have the advantage that NT has at least _some_ debugging tools,
> although they are not that helpful with an interpreted program, like a
> GAP program.
>
> One peculiarity that may have something to do with the NT port: following the
> DOS tradition, STDERR is unbuffered, with a separate handle from STDOUT even
> when both point to the same physical device.  So I am not sure that the
> comment below about the error output taking place during output of the final
> fibonacci number is really significant.
>
> Matthew Johnson
> Firepower Systems
> Menlo Park California
>
> # fibonacci numbers
> # This program computes Fibonacci numbers and culls the same for primes.
>
> # With the call to IsPrimeInt, this program crashes on the 2971st Fibonacci number
> # All I have been able to find with my primitive tools is that the function call stack
> # is filled with repetitive calls to a EvFunccall (apparently to evaluate IsPrimeInt itself)
> # after which the exception is generated on a call to NewBag()
> # Oh yes, running with the '-g' option shows this crash occurs during/after garbage
> # collection, which in turn takes place before the last Fibonacci number has been
> # entirely printed out.
>
> # Use the following for recursive computation of F(n)
> i := 3;
>
> g := 1;
> fib := [1, 1, 2];
> while i<2972 do     # On NT crashes on 2971
>     j := 1;
>     nfib := fib[i] + fib[i-1];
>     Add(fib, nfib );
>     Print("\nfib[",i+1,"] = ", fib[i+1]);
>     test := IsPrimeInt(nfib);          # the failure appears to be here
>     if test = true then
>         Print("\n\tIsPrimeInt = TRUE");
>     fi;
>     i := i+1;
> od;
>
>
>



From wdj@sma.usna.navy.mil Mon Feb  5 12:02:08 1996
Date:           Mon, 05 Feb 96 12:02:08 -0500
From:           "W. David Joyner" <wdj@sma.usna.navy.mil>
Subject:        Shrink/ AbStab.g (reply)

Dear Forum and Martin Schoenert:

 I want to thank everyone for their kind responses regarding my GRAPE/
Cayley graph question and my AbSTab.g/Shrink question.
 I hope I am not beating this poor AbStab.g horse/thread to death but I
still am having problems with the Shrink command which I cannot
resolve. I hope I am not wasting bandwidth but I would like to
respond in the hopes of clarifying the actual result which, to me,
suggests that Shrink might be the cause of the problem. (Though quite
possibly I'm wrong.)

> From GAP-Forum-Sender@Math.RWTH-Aachen.DE Fri Feb  2 09:14 EST 1996
> Sender: GAP-Forum-Sender@Math.RWTH-Aachen.DE
> Reply-To: GAP Forum <GAP-Forum-Reply@Math.RWTH-Aachen.DE>
> X-Miles:        GAP Forum article 818 accepted at 02 Feb 96 13:51 +0100
> Date:           Fri, 02 Feb 96 12:46:00 +0100 (MET)
> From: Martin Schoenert <martin.schoenert@math.rwth-aachen.de>
> To: Multiple recipients of list <GAP-Forum@Math.RWTH-Aachen.DE>
> Subject:        Re: Re: AbStab.g
> Content-Type: text
> Content-Length: 3732
>
> W. David Joyner wrote in his e-mail message of 1996/01/31
>
>     I'll explain why I think abstab.g has an error. I used GAP and abstab.g
>     for the group of the masterball, which has size ~4.3x10^26. I usually
>     can eventually get the masterball into one of two ``nearly solved''
>     positions: one requiring a 2-cycle and the other requiring a 3-cycle.
>     Shrink in abstab.g gives a ~90 move long solution to the 3-cycle position
>     which works. I checked this on my maple implementation and by hand.
>     Shrink gives a slightly longer solution for the 2-cycle. It does
>     not work by my maple computer implementation nor by hand. Moreover,

I ran the calculation again. For the 2-cycle, I got back a (long) word using
FactorPermGroupElement and two different shorter words using Shrink twice.
Then I converted them all into MAPLE notation and plugged them each into
my MAPLE implementation for the masterball. The long work (using FactorPermGroupElement)
worked as expected, while *neither* of the shorter words (using Shrink) worked. This
makes me think that there is something wrong with Shrink. I did the same
thing with a 3-cycle and all of the words worked. The only problem, which
I have duplicated 3 or 4 times now, is with 2-cycles. It is possible that
I am causing the mistake in converting to MAPLE notation, of course, but I don't see
how since I am using the same procedure for all the words and it is only
the words obtained from Shrink applied to a 2-cycle which I have a problem
with.

>     the ``word'' returned by Shrink is *not* equal to the ``word'' returned
>     by FactorPermGroupElement. This makes me suspicious.
>
> Well there are many words representing a particular element of your
> group.  'FactorPermGroupElement' simply finds one such word.  'Shrink'
> takes such a word, and then tries to find a shorter word representing the
> same element.  Thus there is no reason that 'FactorPermGroupElement' and
> 'Shrink' should return the same word.  In fact one would usually hope
> that 'Shrink' returns a different word.

Good point. I misunderstood the meaning of GAP's boolean = function.

> Maybe you are confused by the reording of the generators?  Since you said

Possibly, but as I said above I am using the same procedure to convert between
the generators and so far, except for the case of a word obtained by Shrink
on a 2-cycle, the conversion seems to be correct.

> 'gen:=Set([f1,f2,f3,f4,r1,r2,r3,r4]);', GAP reorders the generators, so
> 'g1' corresponds to 'r4', 'g2' corresponds to 'r3', 'g3' corresponds to 'r2',
> 'g4' corresponds to 'f4', 'g5' corresponds to 'f3', 'g6' corresponds to 'f2',
> and 'g7' corresponds to 'r1'.  I must confess that I don't understand
> why you apply 'Set' to the generators list, why not simply take it as it is?

A better idea. I thought MinGenSet required a set but I'll just use Group
instead.

>
> By the way.  The banner in the log says you are still running GAP 3.2.
> The latest release is GAP 3.4.3.
>
> Martin.

You also say:

    gap> map( G, cycle2a );
    ( 1, 2)
    gap> map( G, cycle2b );
    ( 1, 2)

which implies that the long ('FactorPermGroupElement') word equals the short
('Shrink') word obtained from the 2-cycle. Good point. So, on one hand Shrink is
correct but on the other it seems to produce an incorrect result (in MAPLE). I don't
understand the problem. Note that a 2-cycle is not possible in the Rubik's cube
group (though 3-cycles are), so that my experience does not appear to be inconsistent
with other people's use of Shrink for the Rubik's cube.

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



From martin.schoenert@math.rwth-aachen.de Wed Feb  7 00:55:00 1996
Date:           Wed, 07 Feb 96 00:55:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Re: problems with IsPrimeInt

Matthew Johnson wrote in his e-mail message of 1996/02/01

    However, the following bug also appears under the Mac and NextStep builds
    of the same version of the kernel and relevant libraries.  The bug is
    largely explained in the comments of the code, but I will say here that
    removing the call to IsPrimeInt() makes the problem go away; I will also
    say that the crash may appear with a quite different error message if any
    other code is added to the loop or if run under the Mac or NextStep
    versions: under NextStep (a GUI-enhanced MACH UNIX) I usually get a
    "Segmentation Fault", under NT I usually get a "STack Overflow" (but
    occasionally as in NExtStep), under MacOS 7.5 I get Segmentation Fault.

Burkhard Hoefling wrote in his e-mail message of 1996/02/05

    The reason for Mathew's problem is simply a stack overflow, caused by
    performing prime tests on large integers (large strong pseudoprimes for
    the base 2, to be more precise).

It is correct that 'IsPrimeInt' uses quite a bit of stack space.
'IsPrimeInt' uses a Lucas pseudoprime test for integers that have no
factor less than 1000 and which are strong pseudoprimes for the base 2.
This test computes the trace of an element recursively, where the depth
of the recursion is roughly the number of bits of the tested integer.

What surprises me is that the problem reportedly happens under NextStep.
NextStep should give each process more stack space than what is needed
for 'IsPrimeInt( Fibonacci( 2971 ) );'.

Burkhard continued

    In so far, the GAP manual is wrong in claiming that IsPrimeInt can test
    numbers with "a few hundred digits".

Well, 'IsPrimeInt' *can* test 'Fibonacci( 2971 )'.  But of course it
needs enough resources.  On the machine under my desk (a Pentium@90MHz
under FreeBSD 2.1) it needs about 280 KByte stack, 500 KByte heap, and it
takes about 80 seconds.

Burkhard continued

    To be more technical, IsPrimeInt performs various prime tests (see the
    manual and the documentation in Integer.g for details), and the 2971th
    Fibonacci number is the first to pass all tests except for the last one
    (to be more precise, it is a strong pseudoprime for the base 2). The last
    (probabilistic) prime test uses recursion to check whether a number is a
    prime, and for the 2971th Fibonacci number, this would require a
    recursion depth of about 2600, each call requiring about 160 bytes on my
    Macintosh this should be system dependent. Thus a (program) stack of
    about 400 Kilobytes would be required for this calculation, while the
    usual stack size for GAP seems to be about 64 Kilobytes.

To be precise.  'Fibonacci(2971)' is not the first Fibonacci number that
passes all tests except the last one.  The following numbers also pass
all tests except the last one (in fact all also pass the last one too):
3,4,5,7,11,13,17,23,29,43,47,83,131,137,359,431,433,449,509,569,571.
But apparently they are not large enough to trigger this problem.
The recursion depth for 'Fibonacci(2971)', by the way, is 2063.

Burkhard continued

    - Since this phenomenon is very likely to occur also in other contexts,
    GAP should check whether there is still enough processor stack space when
    doing a (recursive) function call. This is, of course, system dependent,
    and there should be a function in the system dependent part of GAP which
    would then be called before every function call. This, of course, does
    not resolve the problem with IsPrimeInt, but it helps finding such
    problems.

The problem with that is, that it would slow down GAP function calls.
For many computations the speed of function calls is critical for the
overall speed.  But it could be a compile time option.

Also finding out how much stack space is available and how much is used
for each function frame is very system dependent.

Note that on UNIX workstations this is generally not such a problem.
They provide much (virtual) stack space.  Also, if you exhaust the stack
you don't overwrite the heap (I think this is what happens on the Mac).
Instead the GAP kernel is terminated, which is bad enough of course,
but that can't lead to undetected errors.

Burkhard continued

    - Perhaps it is useful to use another prime test. For example, as far as
    I remember from my lectures on number theory, a reasonable solution is to
    pick r positive integers n_1, ... n_r at random, and to check whether the
    number p in question is a strong pseudoprime with respect to all the
    numbers n_1, ... , n_r. Choosing the number r large enough, the
    probability that p is not a prime can be made as close to zero as
    desired. (But don't quote me on the details ...).

The combination of an ordinary pseudoprime test and a Lucas test (as used
in GAP) is generally considered to be stronger than a number of repeated
ordinary pseudoprime tests.  One reason is, that an integer that is a
pseudoprime w.r.t. one base is quite likely a pseudoprime w.r.t. other
bases as well.  There are known integers that are pseudoprimes w.r.t. to
all bases less than 100.  But there are no known integers that fool the
combined test used by GAP.

Furthermore the algorithm used by GAP's 'IsPrime' is not per se
recursive.  Only the current implementation of the function 'TraceModQF'
is recursive.  This could be replaced by a non-recursive implementation.

Martin.

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



From thomas.breuer@math.rwth-aachen.de Thu Feb  8 17:46:00 1996
Date:           Thu, 08 Feb 96 17:46:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        minor bug in GAP-3.4.3

Dear GAP-forum,

I have to report a bug in version 3.4.3 of GAP.
It does not cause wrong results.
But it may happen that GAP signals an error when computing
the intersection of two AG groups.

This bug can be fixed by replacing the assignment

    B := Base( V );

in the definition of 'AgGroupOps.AffineOperation' in file 'agsubgrp.g'
by

    if IsRec( V ) then
      B := BasisVectors( Basis( V ) );
    else
      B := V;
    fi;

Sorry for the inconveniences
Thomas Breuer



From mikec@math.ubc.ca Thu Feb  8 16:54:26 1996
Date:           Thu, 08 Feb 96 16:54:26 -0800
From:           "Michael B. Cherkassoff" <mikec@math.ubc.ca>
Subject:        Question on ConjugacyClassesSubgroups.

Dear GAP-Forum.

I need to do some computations of the conjugacy classes
of certain subgroups in PSL(n,q). (Actually, q=3 would be
enough to look at). I am only interested in Z2+Z2 subgroups.
When I tried to use ConjugacyClassesSubgroups for this
purpose gap can't even handle PSL(5,3):

gap> gg:=ProjectiveSpecialLinearGroup(5,3);;
gap> cc:=ConjugacyClassesSubgroups(gg);;
gap: sorry, cannot extend the workspace, maybe use option '-a <memory>'?

(This was after about half an hour of calculation).

Since I only need very small amount of information the
ConjugacyClassesSubgroups compute, there must be a way
to dig up the code and use only the parts I need, thus handling
this and higher dimensional cases. (For example, I'm
pretty sure that there are only 4 different conjugacy classes
of Z2+Z2 in PSL(5,q)).

So I'm asking for advise on digging the code - like where
would be the good place to start, and also maybe experts
can point to some better way of doing it.

Thanks,
Michael.



From mikec@math.ubc.ca Thu Feb  8 17:41:45 1996
Date:           Thu, 08 Feb 96 17:41:45 -0800
From:           "Michael B. Cherkassoff" <mikec@math.ubc.ca>
Subject:        Re: Question on ConjugacyClassesSubgroups.

Dear GAP-Forum,

Sorry, I did not leave my email address:

mikec@math.ubc.ca

Thanks,
Michael Cherkassoff.



From martin.schoenert@math.rwth-aachen.de Fri Feb  9 15:05:00 1996
Date:           Fri, 09 Feb 96 15:05:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: New documentation

Stuart W. Margolis wrote in his e-mail message of 1996/02/04

    I have a nicely bound version of the GAP documentation for version
    3.2. I've just obtained version 3.4 and have heard that the documentation
    is now over 1000 pages. In order to save some trees, is it possible to
    get an idea of where the new material is and what chapters are worth
    printing out to replace the former version.

The manual has changed quite a bit, as you can see from the following
listing.  It lists for each of the manual '.tex' files how many lines
changed in this file (note that each file corresponds to a chapter).
Each '+' in the bar charts corresponds to roughly 70 added lines,
each '-' corresponds to roughly 70 deleted lines.

    manual   :   61
    preface  :  338 ++--
    aboutgap : 1200 +++++++++++-----
    environm :   60
    ring     :    2
    field    :  240 +--
    aggroup  :  764 ++++++----
    group    : 1151 ++++++++++------
    operatio :   59
    integer  :   49
    algext   N  430 ++++++
    polynom  :  162 +-
    permgrp  :  387 ++++-
    word     :    4
    fpgrp    :  610 +++++---
    aggroup  :  764 ++++++----
    saggroup N  468 ++++++
    list     :   77 -
    set      :    9
    range    :    4
    vector   :    2
    rowspace :  858 +++++++++++-
    matrix   :   30
    grplib   : 2437 ++++++++++++++++++++++++++++++++--
    algebra  N 1021 ++++++++++++++
    algfp    N  479 ++++++
    algmat   N  275 +++
    module   N  570 ++++++++
    mapping  :   16
    record   :   12
    combinat :   81 -
    tom      :   19
    chartabl : 1163 +++++++++-------
    gentable :   15
    characte :  652 +++++----
    paramaps :   20
    gettable :  689 +++++----
    classfun N  785 +++++++++++
    monomial N  575 ++++++++
    install  : 1992 +++++++++++-----------------
    share    : 1644 +++++++++++++++++++----
    anupq    :  413 ++++-
    cohomolo N  249 +++
    dce      N 1362 +++++++++++++++++++
    grape    N 1528 +++++++++++++++++++++
    guava    N 4179 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    mtx      N  945 +++++++++++++
    sisyphos N  406 +++++
    smash    N 1021 ++++++++++++++
    ve       N  432 ++++++
    weyl     :  276 ++-

The lines with 'N' correspond to the 8 new chapters for library stuff
(Algebraic extensions of fields, Special Ag Groups, Algebras, Finitely
Presented Algebras, Matrix Algebras, Modules, Class Functions,
Monomiality Questions) and the 8 new chapters for contributed packages
(Chomology, DCE, GRAPE, Guava, Meataxe, Sisyphos, Smash, and Vector
enumerator).

Hope this helps,

Martin.

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



From alexander.hulpke@math.rwth-aachen.de Fri Feb  9 18:44:33 1996
Date:           Fri, 09 Feb 96 18:44:33 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: Question on ConjugacyClassesSubgroups

Dear GAP-Forum,

Michael Cherkassoff asked:

> I need to do some computations of the conjugacy classes
> of certain subgroups in PSL(n,q). (Actually, q=3 would be
> enough to look at). I am only interested in Z2+Z2 subgroups.
> When I tried to use ConjugacyClassesSubgroups for this
> purpose gap can't even handle PSL(5,3):
>
> gap> gg:=ProjectiveSpecialLinearGroup(5,3);;
> gap> cc:=ConjugacyClassesSubgroups(gg);;
> gap: sorry, cannot extend the workspace, maybe use option '-a <memory>'?
>
> (This was after about half an hour of calculation).

That's no wonder. The order of PSL(5,3) is of magnitude 10^12. Usually
the  subgroup      lattice  computation    (which   is   called   from
ConjugacyClassesSubgroups) works only reasonably for groups of size up
to 10^4-10^5. Of course you can  find representatives of all subgroups
isomorphic V4 in the  2-Sylow subgroup, but I guess  you'll find a lot
of them.  Fusing them under operation of  the whole group is likely to
be very tedious.

So I suggest the following approach:

Every V4 is  generated by two elements  of order two. We can conjugate
the group so  that the first of  these is a class  representative. The
second only has to be determined up to  conjugacy with the centralizer
of the first.  I give an example run:

Create the group (BTW: This is not a GAP library command but a separate
function I sent you some time ago)

gap> g:=ProjectiveSpecialLinearGroup(5,3);
ProjectiveSpecialLinearGroup(5,3)
gap> Size(g);
237783237120

Compute all classes of elements of Order 2. We could use 'ConjugacyClasses'
and 'Filtered'. However there is an internal function that does less work:
For order 2, rational classes are the same as conjugacy classes.

gap> cl:=RationalClassesPElements(g,2);;

We don't want those of 2-power order

gap> cl:=Filtered(cl,i->Order(g,i.representative)=2);;
gap> Length(cl);
2

there  are  only two  classes  to consider.   As  V4 has 3  nontrivial
elements,  each  V4 contains  at least  two  elements of  one of these
classes.  So every V4  is generated by two  elements of class 1 or two
elements of class 2.

The classes differ in size and the cycle structure of their elements

gap> List(cl,Size);
[ 9801, 882090 ]
gap> List(cl,i->CycleStructurePerm(i.representative));
[ [ 40 ], [ 52 ] ]

We can always conjugate  a V4, so that  the first generator is one  of
the   two  representatives. Then  we can  still   conjugate the second
generator with the centralizer of the first.

So we just  need to consider representatives  of centralizer orbits on
the classes. These of course correspond to double cosets:

gap> dc:=DoubleCosets(g,cl[1].centralizer,cl[1].centralizer);;

The corresponding class elements are obtained by conjugacy

gap> r:=List(dc,i->cl[1].representative^i.representative);;

There are 8 reps to consider, but only 2 commute with the first generator



From thomas.breuer@math.rwth-aachen.de Fri Feb  9 19:09:00 1996
Date:           Fri, 09 Feb 96 19:09:00 +0100 (MET)
From:           "Thomas Breuer" <Thomas.Breuer@Math.RWTH-Aachen.DE>
Subject:        group rings in GAP

Dear GAP-Forum,

recently the question was asked how to deal with group rings
of not too big groups in GAP.
I had promised to figure out whether the programs written by
Philip Osterlund could be made public, Philip has agreed,
and so I have put his file 'groupring' into the 'pub/incoming'
directory of our server.

Have fun with it,
Thomas Breuer



From osterlu@s5.math.umn.edu Fri Feb  9 15:51:11 1996
Date:           Fri, 09 Feb 96 15:51:11 -0600
From:           "Philip Osterlund" <osterlu@s5.math.umn.edu>
Subject:        AbStab.g

Dear gap forum:
     As there has been discussion about the AbStab.g package, I need to respond.

     I would like to describe some algorithms used in my package, AbStab.g, to
express an element of permutation group as a word in the generators.
     We start by constructing a stabilizer chain in a manner similar to
MakeStabilizerChain.  For each subgroup in the stabilizer chain, the generators
are stored both as permutations and as abstract words, derived from the
generators of the next larger stabilizer subgroup.
     Let H represent a subgroup in the stabilizer chain, and K the next subgroup
in the chain.  (K is the stabilizer in H of some point p.)  Let the generators
of H be {g1, ..., gk}.  The generators of K are found by first taking a left
Schreier transversal for the cosets of H in K with respect to these generators.
     For each x in H, let \overbar{x} be the element of the Schreier transversal
which represents the same coset stabilizer.  Then H may be generated by the
elements { u^-1 * gi * \overbar{u^-1 * gi} }, where u ranges over the elements
of the Schreier transversal, and gi ranges over the generators of H.  (As p is
the point stabilized, u^-1 * gi * \overbar{u^-1 * gi} :p -> k -> q -> p, when
following the action of each element of the multiplication, i.e. p^u = k...)
(see D.L. Johnson, Presentations of groups (1990) )
     This set of elements is often much larger than needed.  We sort them
according to length.  The function MinGenSet then adjoins these generators
one by one, in order of length, starting with the shortest.  If the next
generator actually increases the size of the subgroup generated, it is retained,
otherwise it is discarded.  We finish with a small list of short generators for
the stabilizer K.  This is repeated to stabilize the next point, until the
trivial subgroup is obtained.

     Once the abstract stabilizer chain has been found, it is fairly trivial to
take an element x of the group and find an expression for it as a word in the
generators of the group.  Assume that G is a permutation group on { 1..n }.
For each point p let Gp represent the stabilizer of [1..p-1] in G.  Let x_p
denote an element of Gp obtained inductively with p, starting with x_1=x.  We
let x_{p+1} := x_p * s, where s is the element of the Schreier transversal of
the form (p^x_p, p, ....).  Then x_{p+1} will fix the point p.  This causes
x_n = ().  (If x_n <> (), then x was not in the group to begin with.)  This
results in an expression for x.


     The function Shrink attempts to find a shorter representation for an
element of G.  Let x be in G, and g*w represent x as a product of generators,
g a generator, and w a word.  Then look for the shortest word in the following
lists:  {w}, {FactorPermGroupElement(h*x) | h or h^-1 in G.generators},
             {FactorPermGroupElement(x*h) | h or h^-1 in G.generators}.
     Then replace g*w by g'*w' or w'*g', where w' is this shortest word, and
g' =g or h, as above.  The is repeated with w', until w' is of length 1.

     I now give an example of AbStab.g.  Note the method used for choosing the
names of the abstract generators.

...
gap> gen:=Set([f1,f2,f3,f4,r1,r2,r3,r4]);
[ (25,26,27,28,29,30,31,32), (17,18,19,20,21,22,23,24),
  ( 9,10,11,12,13,14,15,16), ( 4,31)( 5,30)( 6,29)( 7,28)(12,23)(13,22)(14,21)
    (15,20), ( 3,30)( 4,29)( 5,28)( 6,27)(11,22)(12,21)(13,20)(14,19),
  ( 2,29)( 3,28)( 4,27)( 5,26)(10,21)(11,22)(12,23)(13,24), (1,2,3,4,5,6,7,8),
  ( 1,28)( 2,27)( 3,26)( 4,25)( 9,20)(10,19)(11,18)(12,17) ]
gap> G := Group(gen,());;
gap> G.abstractGenerators := Union(AbstractGenerators("f",4),
>                               AbstractGenerators("r",4) );
[ f1, f2, f3, f4, r1, r2, r3, r4 ]
gap> 2_cycle:=(1,2);
(1,2)
gap> cycle2a:=FactorPermGroupElement(G,2_cycle);
f1^2*r1*r3* ... *r3^-1*r1^-1*f1^-2
<< a word of length 409 >>
gap> cycle2b:=Shrink(G,cycle2a);
f1^-2*r1^-1*f1* ... *r1^-1*r3^-1*r1^-1
<< a word of length 107 >>
gap> cycle2d := Shrink(G,(1,2));;
gap> cycle2d = cycle2c;
true
gap> map( G, cycle2a );
( 1, 2)
gap> map( G, cycle2b );
( 1, 2)
gap>

     By no means does this package claim to give the shortest solution.  It may
be observed that asking the points to be stabilized in a different order may
make a significant difference on the length of a solution given (both in length
of word and time.)
     Finally I should note that there are a number of aspects of these routines
which ideally should be reworked to make them more efficient and robust.

     There is a small change that should be made to one of the functions, due
to a change of the implementation of the function List.  This suggestion was
made by Heiko Theissen:

--- AbStab.g.orig   Fri Oct 28 21:34:03 1994 # GAP V3R4P2 (or earlier)
+++ AbStab.g    Wed Jan 31 10:41:19 1996     # GAP V3R4P3
@@ -210,8 +210,10 @@
     lt:=LeftSchreier(arg);
     alt:= lt.ASchreier;
     lt := lt.Schreier;
-    rt:=List(lt,x->x^-1);
-    art:=List(alt,x->x^-1);
+    # rt:=List(lt,x->x^-1);
+    # art:=List(alt,x->x^-1);
+    rt:=[]; for x in lt do Add( rt, x^-1 ); od;
+    art:=[]; for x in alt do Add( art, x^-1 ); od;
     for g in G.generators do
        i:=Position(G.generators, g);
        ag := G.abstractGenerators[i];

     This should fix any problems, as all other calls to the function "List" do
not implement a list with gaps in it.


                                                Philip Osterlund
                                                February 9, 1996
                                                University of Minnesota
                                                osterlu@math.umn.edu



From martin.schoenert@math.rwth-aachen.de Fri Feb  9 23:03:00 1996
Date:           Fri, 09 Feb 96 23:03:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Shrink/ AbStab.g (reply)

David Joyner wrote in his e-mail message of 1996/02/05

    I hope I am not beating this poor AbStab.g horse/thread to death but I
    still am having problems with the Shrink command which I cannot
    resolve. I hope I am not wasting bandwidth but I would like to respond in
    the hopes of clarifying the actual result which, to me, suggests that
    Shrink might be the cause of the problem. (Though quite possibly I'm
    wrong.)

'Shrink' is *definitely* not the cause of the problem.  It does exactely
what it should be doing.  This can be seen as follows.  If you define
r1,r2,r3,r4,f1,f2,...,f8 as in your e-mail message of 1996/01/31, and set

    g1:=r4;; g2:=r3;; g3:=r2;; g4:=f4;; g5:=f3;; g6:=f2;; g7:=r1;;

and then evaluate the word found by 'Shrink':

    g1^-2*g5^-1*g1*g4^-1*g1*g4^-1*g1^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-3
    *g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1
    *g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^-4*g5^-1*g7
    *g5^-1*g1*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^-2*g5^-1*g1^-1*g5^-1*g7*g5^-1
    *g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7^4*g5^-1*g1*g5^-1*g7^-3*g5^-1
    *g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^3*g5^-1*g1
    *g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1;

You get the 2-cycle '(1,2)' (I just did it by cutting and pasting
everything into a GAP, and yes it worked).  I also get '(1,2)'
when I evaluate the long word found by 'FactorPermGroupElement'.

If evaluating this word in Maple does not give '(1,2)' (or whatever
represents the 2-cycle in your Maple model), then there must be a
difference between the GAP and the Maple model.

Martin.

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



From pasec@can.nl Sun Feb 11 01:48:35 1996
Date:           Sun, 11 Feb 96 01:48:35 +0000
From:           "Dima Pasechnik" <pasec@can.nl>
Subject:        Speeding up FpAlgebra() for matrix algebras

Dear Forum,
In the present form FpAlgebra() does not produce very efficient
presentation for matrix algebras; it basically takes the complete
multiplication table for the set of defining relations.

A revised version of this function which produces a presentation
in some sence irredundant is now available from me;
(I don't post it now since I'm not sure if many people might find
it useful)
In fact, it is easy to use the idea behind the  way the presentation is
computed by my version to speed up StandardBasis() computation for a
matrix algebra.

Best regards,
Dmitrii Pasechnik <dima@win.tue.nl>



From sal@dcs.st-andrews.ac.uk Mon Feb 12 19:17:15 1996
Date:           Mon, 12 Feb 96 19:17:15 +0000
From:           "Steve Linton" <sal@dcs.st-andrews.ac.uk>
Subject:        GAP Bibliography -- revised

As I announced late last year, I have been compiling a bibliography of works
which cite GAP, or describe research in which I know GAP has been used. Since
my first announcement  I have received a number of corrections, and I have put
new versions on the Web at http://www-theory.dcs.st-and.ac.uk/~sal/GAP/biblio.

Corrections and suggestions are welcomed.


Steve



From pfm@math.ufl.edu Wed Feb 14 20:28:34 1996
Date:           Wed, 14 Feb 96 20:28:34 -0500
From:           "Peter F. Mueller" <pfm@math.ufl.edu>
Subject:        SymmetricNormalizer

Dear Gap-Forum,

if I remember correctly, then CAYLEY used to have a very fast function
which computed the normalizer of a permutation group on the letters
[1..n] inside the symmetric group on these letters.

Is there a substitute for this in GAP? Something like

s:=SymmetricGroup(n); ng:=Normalizer(s,AsSubgroup(s,g));

works in general already unusably slowly already for n>25.

- Peter M\"uller



From volkmar.felsch@math.rwth-aachen.de Fri Feb 16 14:11:29 1996
Date:           Fri, 16 Feb 96 14:11:29 +0100
From:           "Volkmar Felsch" <Volkmar.Felsch@Math.RWTH-Aachen.DE>
Subject:        Bug in Tietze routines

    This mail contains a fix for two bugs in 'TzFindCyclicJoins'.
    'TzFindCyclicJoins' is called directly or indirectly from
    'FpGroup' (when called for subgroups of finitely presented groups),
    'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo', and 'TzGoGo'.

    The priority of this bug fix is *high*, because one of the bugs may lead
    to wrong results without a warning.

    This bug fix changes only the library.  Thus you need not recompile the
    GAP kernel.

    Go to the GAP directory (the directory with the 'lib/' subdirectory),
    name this bug fix file 'bugfix01.dif', and issue the command:

        patch -p0 < bugfix01.dif


COMMENT

    This fix simply disables the faulty function 'TzFindCyclicJoins'.
    A later fix will provide a corrected version of 'TzFindCyclicJoins',
    since we first want to test the corrected version.

    'TzFindCyclicJoins' has the following purpose.  If the presentation being
    simplified contains a commutator relator 'Comm(<a>,<b>)' and at least one
    power relator of the form '<a>^<n>' or '<b>^<m>', where <a> and <b> are
    generators or inverses of generators, then the subroutine searches for
    further relators which are words in <a> and <b> and their inverses only,
    and then it tries to reduce these relators by applying the Euclidean
    algorithm to the occurring exponents.

    The fact that this bug has been discovered only now in a routine which is
    being used since 1993 seems to indicate that it only occurs in rather
    rare situations.  Unfortunately, however, it is one of those nasty bugs
    which may produce wrong results without giving any evidence of that fact.
    Therefore we strongly recommend that you implement this fix in your local
    GAP installation.


VERSION

    GAP 3.4.3.0
    @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $


DESCRIPTION

    'TzFindCyclicJoins', which is is called directly or indirectly from
    'FpGroup' (when called for subgroups of finitely presented groups),
    'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo', and 'TzGoGo',
    might signal

        Error: Integer operations: <divisor> must be nonzero.


DESCRIPTION

    'TzFindCyclicJoins', which is is called directly or indirectly from
    'FpGroup' (when called for subgroups of finitely presented groups),
    'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo', and 'TzGoGo',
    might produce wrong presentations.


FIX

Prereq: 3.4.1.2
--- lib/fptietze.g      1995/11/03 10:56:47
+++ lib/fptietze.g      1996/02/16 10:56:09
@@ -2,7 +2,7 @@
 ##
 #A  fptietze.g                GAP library                      Volkmar Felsch
 ##
-#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
+#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
 ##
 #Y  Copyright 1990-1992,  Lehrstuhl D fuer Mathematik,  RWTH Aachen,  Germany
 ##
@@ -10,6 +10,9 @@
 ##  finitely presented groups.
 ##
 #H  $Log: forum96a.txt,v $
 #H  Revision 1.1  1997/04/06 10:38:29  gap
 #H  Added forum archives (ahulpke)
 #H
+#H  Revision 3.4.1.3  1996/02/16  09:58:00  vfelsch
+#H  commented out the call of TzFindCyclicJoins which contains a bug
+#H
 #H  Revision 3.4.1.2  1995/11/03  10:56:47  werner
 #H  fixed a bug in TzHandleLength1Or2Relators()
 #H          (discovered by a run of Tibor & Zoltan space group routines)
@@ -1412,11 +1415,11 @@

     # try to find cyclic subgroups by looking at power and commutator
     # relators.
-    if tietze[TZ_TOTAL] > 0 then
-        TzFindCyclicJoins( T );
-        if tietze[TZ_MODIFIED] then  TzSearch( T );  fi;
-        if printstatus then  TzPrintStatus( T, true );  fi;
-    fi;
+    ## if tietze[TZ_TOTAL] > 0 then
+    ##     TzFindCyclicJoins( T );
+    ##     if tietze[TZ_MODIFIED] then  TzSearch( T );  fi;
+    ##     if printstatus then  TzPrintStatus( T, true );  fi;
+    ## fi;

 end;

END OF  mail



From heiko.theissen@math.rwth-aachen.de Wed Feb 21 10:25:00 1996
Date:           Wed, 21 Feb 96 10:25:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        Re: SymmetricNormalizer

Dear GAP forum,

Peter M"uller  has  asked in the GAP   forum whether there is   a special
normaliser  function in GAP  for   normalisers  in the symmetric   group,
similar to `SymmetricNormalizer' in CAYLEY. Well, in GAP-3.4 there isn't.

I can imagine only one advantage that you have  from the symmetric group:
you do not have  to set up a stabiliser  chain for S_n, because you  know
that  every element you will enumerate  during the backtrack search is in
S_n. In GAP-3.4,  only setting  up a stabiliser   chain for S_n  takes  a
considerable amount of  time (12 sec for S_25,   180 sec for S_50  on our
machine). In the next release of GAP (which  will be the first release of
GAP-4), we will avoid the stabiliser chain construction  in the case of a
symmetric group.

I have  asked Peter M"uller with separate  mail to  give an example where
GAP's normaliser function is unusably slow. He has told me that he wanted
to compute the normaliser  of Sz(8) on 65 points  in the symmetric group.
This subgroup is doubly transitive, and this makes  it harder to think of
methods which allow substantial pruning of the  search tree through which
the backtrack algorithm for `Normalizer' has  to run. (A prototype of the
normaliser function  to be released with GAP-4   does this calculation in
about  15  seconds,  but  it   cannot  do so  well  for  all 2-transitive
subgroups.)

There is an alternative approach to this particular  problem which can be
realised  in   GAP-3.4:  Since  Sz(8)  is  a    simple  group, its  outer
automorphism group is  known, it is of  order 3. If  one has a generating
automorphism  for this cyclic group, it  only  remains to test whether it
can be realised in S_65. The following commands do this:

gap> S := SymmetricGroup(65);;
gap> G := <Suz(8) on 65 points>;;

# `PermGroupOps.RationalClasses' is too slow on <G>, so ...
gap> G.rationalClasses := GroupOps.RationalClasses( G );;

# `AutomorphismGroup' needs `<G>.rationalClasses'.
gap> aut := AutomorphismGroup( G );;
gap> out := aut.generators[4];;

# The  following function is probably too   slow, better use the function
# below instead.
gap> x := RepresentativeOperation( S,
> out.generators, out.genimages, OnTuples );;

The function makes use of the following lemma:

Let $G$ and  $H\le S_n$ be transitive  groups, $G_1$ and $H_1$ the  point
stabilisers and  $f:  G ->  H$  an isomorphism.  Then  $f$ is realised by
conjugation in  $S_n$ if and only  if $f(G_1)$ is  conjugate to  $H_1$ in
$H$.

#########################################################################
##
#F  AutomorphismByConjugation( <Omega>, <d>, <e> ) do auto by conjugation
##
AutomorphismByConjugation := function( Omega, d, e )
    local   bpt,  aut,  D1,  E1,  fix,  Imega,  sliced,  pnt,  img,  j;

    aut := GroupHomomorphismByImages( Group( d, () ), Group( e, () ),
                                      d,              e );
    aut.coKernel := TrivialSubgroup( aut.source );
    if not IsTransitive( aut.source, Omega )  then
        Error( "<d> and <e> must generate transitive subgroups of <G>" );
    elif not IsTransitive( aut.range, Omega )  then
        return false;
    fi;

    bpt := Omega[ 1 ];
    D1 := Stabilizer( aut.source, bpt );
    E1 := Image( aut, D1 );
    if PermGroupOps.NrMovedPoints( E1 ) = Length( Omega )  then
        return false;
    fi;
    fix := First( Omega, p ->
                  ForAll( E1.generators, gen -> p ^ gen = p ) );

    # The  automorphism <aut> maps  <d>_bpt  to <e>_fix, so permutes  the
    # points. Find an element in <G> with the same action.
    Imega := [  ];
    for pnt  in Omega  do
        sliced := [  ];
        while pnt <> bpt  do
            Add( sliced, aut.transimages[ pnt ] );
            pnt := pnt ^ aut.transversal[ pnt ];
        od;
        img := fix;
        for j  in Reversed( [ 1 .. Length( sliced ) ] )  do
            img := img / sliced[ j ];
        od;
        Add( Imega, img );
    od;

    return MappingPermListList( Omega, Imega );
end;

gap> x := AutoByConjugation( [ 1..65 ], out.generators, out.genimages );
( 1,27,51)( 2,43, 7)( 3,12,56)( 4,39,60)( 5,41,65)( 6,36,19)( 9,35,29)
(10,37,22)(11,23,58)(14,28,59)(15,45,55)(16,57,30)(17,61,46)(18,34,32)
(20,24,49)(21,50,54)(25,38,44)(31,48,42)(33,52,64)(47,53,62)
gap> N := Closure( G, x );;
# <N> is the normaliser.

Hope this helps, Heiko Thei{\ss}en



From dfh@maths.warwick.ac.uk Wed Feb 21 12:05:01 1996
Date:           Wed, 21 Feb 96 12:05:01 +0000 (GMT)
From:           "Derek Holt" <dfh@maths.warwick.ac.uk>
Subject:        Re: SymmetricNormalizer

Dear GAP forum,

Heiko Theissen wrote:

> Peter M"uller  has  asked in the GAP   forum whether there is   a special
> normaliser  function in GAP  for   normalisers  in the symmetric   group,
> similar to `SymmetricNormalizer' in CAYLEY. Well, in GAP-3.4 there isn't.
>
> I can imagine only one advantage that you have  from the symmetric group:
> you do not have  to set up a stabiliser  chain for S_n, because you  know
> that  every element you will enumerate  during the backtrack search is in
> S_n. In GAP-3.4,  only setting  up a stabiliser   chain for S_n  takes  a
> considerable amount of  time (12 sec for S_25,   180 sec for S_50  on our
> machine). In the next release of GAP (which  will be the first release of
> GAP-4), we will avoid the stabiliser chain construction  in the case of a
> symmetric group.
>
> I have  asked Peter M"uller with separate  mail to  give an example where
> GAP's normaliser function is unusably slow. He has told me that he wanted
> to compute the normaliser  of Sz(8) on 65 points  in the symmetric group.
> This subgroup is doubly transitive, and this makes  it harder to think of
> methods which allow substantial pruning of the  search tree through which
> the backtrack algorithm for `Normalizer' has  to run. (A prototype of the
> normaliser function  to be released with GAP-4   does this calculation in
> about  15  seconds,  but  it   cannot  do so  well  for  all 2-transitive
> subgroups.)

(Remainder deleted)

I remember reading about the  CAYLEY `SymmetricNormalizer' function some
time ago (I can't remember where, unfortunately - it might have been
in Butler's article on computing normalizers in permutation groups,
on which the current GAP code seems to be based.) My memory is that
`SymmetricNormalizer' is a significantly different algorithm due originally
(like many others) to Charles Sims.

A transitive permutation group G gives rise to a number of directed or
undirected graphs, each one based on one of the orbits of the stabilizer of G,
and G acts as an automorphism group of each of these grapohs.  The normalizer
of G in the symmetric group (or indeed any of its subgroups) acts in a
well-defined way on these graphs (it may permute them among themselves), and
this information can be used to restrict the backtrack search for the
normalizer. Since, in the case of a 2-transitive group, there is only one
graph and it is complete, it provides no useful information. I presume that
the strategy is to go down to a point stabilsier in that case, and use its
graphs.

I don't think there was any particular reason why this was only coded in
CAYLEY for the symmetric group. It was probably just done for that case, and
further work on it got postponed indefinitely.

It is true that SymmetricNormalizer returns the answer almost immediately
for Sz(8) (I just tried it), and other similar examples where there is
plenty of information to be got out of the graphs. Unfortunately, it is not
likely to be easy to combine the SymmetricNormalizer algorithm with the
one currently in GAP, since they involve rather different structures.

In any case, there are examples in which both methods fail miserably, the
most obvious being when the group acts regularly (transitively and with
trivial stabilizer), in which case there is no combinatorial information
to help you at all. In such cases (and others as well), one needs to use
group theory rather than combinatorics, and make use of the fact that the
normalizer of G is inducing automorphisms of G. (This is essentially the
method proposed by  Heiko Theissen  for Sz(8) in the remainder of his letter,
but it has the disadvantage that the user needs to supply information
relevant to the particular example.) I wrote a standalone normalizer
program a few years ago that performed particularly well on regular
groups. Unfortunately, as it stands, it is rather slow on Sz(8), which
has a particuarly bad orbit structure (all orbits of the 2-point stabiliser
have the same length).

It would be nice, in the long term, to have a normalizer function (and
perhaps a related function for testing conjugacy of subgroups in
permutation groups), that worked without complete disaster for all
groups up to degree 100, say!

Derek Holt.



From alexander.hulpke@math.rwth-aachen.de Fri Feb 23 14:35:05 1996
Date:           Fri, 23 Feb 96 14:35:05 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Possible bug in Complementclasses

    This mail contains a fix for the complement routines for AgGroups.

    The priority of this bug fix is *high*, because one of the bugs might
    lead to wrong results without a warning.

    This bug fix changes only the library.  Thus you need not recompile the
    GAP kernel.

    Go to the GAP directory (the directory with the 'lib/' subdirectory),
    name this bug fix file 'bugfix02.dif', and issue the command:

        patch -p0 < bugfix02.dif


COMMENT

    This fix simply disables the faulty treatment of the coprime case when
    complements in AgGroups can be obtained as Hall subgroups.

    The current treatment of this case produces elements at an interim stage
    which should be in the normal subgroup but are not. In the examples
    considered so far this did not lead to wrong results. In fact the bug
    was only detected when including an extra check function intended for
    the test of extended routines.

    We cannot show that this misbehaviour will produce errors at all.
    However we also cannot show the contrary. Thus we recommend to
    apply this fix to your local installation.

VERSION

    GAP 3.4.3.0
    @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $


DESCRIPTION

    'Complementclasses' and 'Complement' might produce wrong results in
    coprime situations.

FIX

Prereq: 3.11.1.1
--- lib/agcomple.g      1995/10/09 09:51:50
+++ lib/agcomple.g      1996/02/22 10:59:28
@@ -2,13 +2,16 @@
 ##
 #A  agcomple.g                  GAP library                      Frank Celler
 ##
-#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
+#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
 ##
 #Y  Copyright 1990-1992,  Lehrstuhl D fuer Mathematik,  RWTH Aachen,  Germany
 ##
 ##  This file contains all polymorph functions for groups.
 ##
 #H  $Log: forum96a.txt,v $
 #H  Revision 1.1  1997/04/06 10:38:29  gap
 #H  Added forum archives (ahulpke)
 #H
+#H  Revision 3.11.1.2  1996/02/22  10:59:28  ahulpke
+#H  disabled erraneous coprime case (only temporary fix)
+#H
 #H  Revision 3.11.1.1  1995/10/09  09:51:50  fceller
 #H  fixed the parameter sequence of 'SumAgGroup' (normal subgroup first)
 #H
@@ -901,13 +904,18 @@
        cor := rec();

     # otherwise we compute a hall system for <G>/<N>
-    else
-       InfoAgCo2( "#I  Complements: computing p prime sets\n" );
+    elif false  then
+        InfoAgCo2( "#I  Complements: computing p prime sets\n" );
         a   := NaturalHomomorphism( G, G / N );
         cor := PPrimeSetsOC( Image( a ) );
-        cor.generators := List( cor.generators, x ->
-                               PreImagesRepresentative( a, x ) );
-       cor.useCentralSK := true;
+        cor.generators := List( cor.generators, x ->
+                                PreImagesRepresentative( a, x ) );
+        cor.useCentralSK := true;
+
+    # use standard algorithm until CoprimeComplement is fixed
+    else
+        cor := rec();
+        cor.useCentralSK := true;
     fi;

     # we want our nice elementary abelian series

END OF  mail



From wdj@sma.usna.navy.mil Fri Feb 23 09:59:12 1996
Date:           Fri, 23 Feb 96 09:59:12 -0500
From:           "W. David Joyner" <wdj@sma.usna.navy.mil>
Subject:        Re: Shrink/ AbStab.g (reply)

> From GAP-Forum-Sender@Math.RWTH-Aachen.DE Fri Feb  9 17:29 EST 1996
> Sender: GAP-Forum-Sender@Math.RWTH-Aachen.DE
> Reply-To: GAP Forum <GAP-Forum-Reply@Math.RWTH-Aachen.DE>
> X-Miles:        GAP Forum article 835 accepted at 09 Feb 96 23:08 +0100
> Date:           Fri, 09 Feb 96 23:03:00 +0100 (MET)
> From: Martin Schoenert <martin.schoenert@math.rwth-aachen.de>
> To: Multiple recipients of list <GAP-Forum@Math.RWTH-Aachen.DE>
> Subject:        Re: Shrink/ AbStab.g (reply)
> Content-Type: text
> Content-Length: 1866
>
> David Joyner wrote in his e-mail message of 1996/02/05
>
>     I hope I am not beating this poor AbStab.g horse/thread to death but I
>     still am having problems with the Shrink command which I cannot
>     resolve. I hope I am not wasting bandwidth but I would like to respond in
>     the hopes of clarifying the actual result which, to me, suggests that
>     Shrink might be the cause of the problem. (Though quite possibly I'm
>     wrong.)
>
> 'Shrink' is *definitely* not the cause of the problem.  It does exactely

Martin:
I finally found the source of my error and you are absolutely right.
I thought the problem was in my maple code, so I ended up rewriting it
3 times, but that wasn't the problem. The problem was that some of
the generators were indexed wrong in my maple input file so even
though everything was correctly computed I misinterpreted the
output. Thanks again for the help. - David

> what it should be doing.  This can be seen as follows.  If you define
> r1,r2,r3,r4,f1,f2,...,f8 as in your e-mail message of 1996/01/31, and set
>
>     g1:=r4;; g2:=r3;; g3:=r2;; g4:=f4;; g5:=f3;; g6:=f2;; g7:=r1;;
>
> and then evaluate the word found by 'Shrink':
>
>     g1^-2*g5^-1*g1*g4^-1*g1*g4^-1*g1^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-3
>     *g5^-1*g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1
>     *g5^-1*g1^2*g5^-1*g7*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1*g1^-4*g5^-1*g7
>     *g5^-1*g1*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^-2*g5^-1*g1^-1*g5^-1*g7*g5^-1
>     *g1^-1*g5^-1*g7^-1*g5^-1*g1^2*g5^-1*g7^4*g5^-1*g1*g5^-1*g7^-3*g5^-1
>     *g1^-1*g5^-1*g7*g5^-1*g1^2*g5^-1*g7^-1*g5^-1*g1*g5^-1*g7^3*g5^-1*g1
>     *g5^-1*g7^-3*g5^-1*g1^-1*g5^-1*g7^2*g5^-1*g1^-1*g5^-1*g7^-1*g5^-1;
>
> You get the 2-cycle '(1,2)' (I just did it by cutting and pasting
> everything into a GAP, and yes it worked).  I also get '(1,2)'
> when I evaluate the long word found by 'FactorPermGroupElement'.
>
> If evaluating this word in Maple does not give '(1,2)' (or whatever
> represents the 2-cycle in your Maple model), then there must be a
> difference between the GAP and the Maple model.
>
> Martin.
>
> -- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
> Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,   +49 241 804551
> Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany
>
>



From heiko.theissen@math.rwth-aachen.de Fri Feb 23 16:35:00 1996
Date:           Fri, 23 Feb 96 16:35:00 +0100 (MET)
From:           "Heiko Theissen" <Heiko.Theissen@Math.RWTH-Aachen.DE>
Subject:        AbStab.g for GAP 3.4.3

Dear GAP forum,

I have put a  new version of the  AbStab.g package by Philip Osterlund
in the `pub/incoming' directory of our ftp server

    ftp.math.rwth-aachen.de

The new version is modified to make the functions  run under GAP 3.4.3
(due to a change of the library function `List', see GAP forum article
814 of 31 Jan). The new version will  also work with older versions of
GAP.

The old version has been removed.

Have fun with the package, Heiko Thei{\ss}en



From alexander.hulpke@math.rwth-aachen.de Fri Mar  1 10:40:58 1996
Date:           Fri, 01 Mar 96 10:40:58 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Share package 'cohomolo'

Dear GAP-Forum,

When adding the 'comomolo' package to GAP in the last patch, some trial code
was accidentally left in. This might cause trouble when using finitely
presented groups together with this package. The remedy is simple:

If you did not install the cohomolo package, nothing has to be changed.

Otherwise, simply edit the file 'init.g' in the directory 'pkg/cohomolo' of
your GAP installation and remove the last paragraph saying:

  AUTO( ReadPkg( "cohomolo", "gap", "darstgr" ),
    IsDiagonalMat, HermiteNormalForm, DiagonalizedMat, WordList,
    Darstellungsgruppe );

We apologize for the error.

     Alexander Hulpke



From michael.smith@maths.anu.edu.au Tue Mar  5 23:01:17 1996
Date:           Tue, 05 Mar 96 23:01:17 +1000
From:           "Michael Smith" <michael.smith@maths.anu.edu.au>
Subject:        documentation of line editing

Dear gap-forum,

The following is an excerpt from the GAP manual ("Line Editing"),

    The next  commands allow  you to fetch  previous lines, e.g.,  to correct
    typos, etc.  This history is limited to about 8000 characters.

    <ctr>-'L'       insert last input line before current character.
    <ctr>-'P'       redisplay  the last input   line, another  <ctr>-'P' will
                    redisplay the line  before that, etc.   If  the cursor is
                    not in the first column  only the lines starting with the
                    string to the left  of the cursor  are taken.
    <ctr>-'N'       Like <ctr>-'P' but goes the other way round  through  the
                    history.
    <esc>-'<'       goes to the beginning of the history.
    <esc>-'>'       goes to the end of the history.
    <ctr>-'O'       accepts this line and perform a <ctr>-'N'.


This should be updated, since the command <ctr>-'O' does not seem to be
implemented. I was delighted to find out today that a feature just like it
exists in GAP already but is not explicitly mentioned in the manual.
Instead of typing <ctl>-'O' to accept the line and edit the historically
following one, simply hit return to accept the line and then press
<ctl>-'N' to receive the next one.

This is a feature I have sorely missed, and only discovered it today by
accident --- perhaps it should be mentioned explicitly in the manual?

(I had assumed that it was my terminal emulator/settings that were causing
the problem with using <ctl>-'O').

Cheers,
Michael.

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



From martin.schoenert@math.rwth-aachen.de Wed Mar  6 10:53:00 1996
Date:           Wed, 06 Mar 96 10:53:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: documentation of line editing

Michael Smith wrote in his e-mail message of 1996/03/05

    The following is an excerpt from the GAP manual ("Line Editing"),

    <ctr>-'L'       insert last input line before current character.
    <ctr>-'P'       redisplay  the last input   line, another  <ctr>-'P' will
                    redisplay the line  before that, etc.   If  the cursor is
                    not in the first column  only the lines starting with the
                    string to the left  of the cursor  are taken.
    <ctr>-'N'       Like <ctr>-'P' but goes the other way round  through  the
                    history.
    <esc>-'<'       goes to the beginning of the history.
    <esc>-'>'       goes to the end of the history.
    <ctr>-'O'       accepts this line and perform a <ctr>-'N'.

    This should be updated, since the command <ctr>-'O' does not seem to be
    implemented. I was delighted to find out today that a feature just like
    it exists in GAP already but is not explicitly mentioned in the manual.
    Instead of typing <ctl>-'O' to accept the line and edit the historically
    following one, simply hit return to accept the line and then press
    <ctl>-'N' to receive the next one.

    This is a feature I have sorely missed, and only discovered it today by
    accident --- perhaps it should be mentioned explicitly in the manual?

    (I had assumed that it was my terminal emulator/settings that were
    causing the problem with using <ctl>-'O').

<ctr>-'O' is implemented (in 'SyFgets') and works fine for me.
There must be some other reason that it doesn't work for you.
I would guess that the <ctr>-'O' is eaten by your terminal driver.
On our FreeBSD 2.1 systems it is the default for the <discard>
special character (which toggles the flushing of terminal output).
I turn it off with 'stty discard undef' in my '.login' file.
I have been told that the command under SunOS is 'stty flush undef'.

The reason that it is not automatically turned off by 'SyFgets'
(the way the <interrupt> and <suspend> special characters are turned off)
is that <discard> and <lnext> (literal next character, usually <ctr>-'V')
are relatively new POSIX additions and are not known on all BSD systems.

I thought it clear that "accepts this line and perform a <ctr>-'N'"
means that <ctr>-'O' is equivalent to <enter>/<ctr>-'N'.

Which feature exactely have you missed and only discovered today?
That <ctr>-'N' starts with the line that historically follows the
line that was edited last?

Note also that <enter>/<ctr>-'N' is not quite equivalent to <ctr>-'O'.
The latter one can be prefixed with a repetition count, the former not.

In case you wonder what all this is about, allow me to describe in more
detail what <ctr>-'N' and <ctr>-'O' do.

Assume you have entered the following code to compute a list of squares

gap> e := 2;;
gap> l := [];;
gap> for i in [1..10] do
>        Add( l, i^e );
>    od;
gap> l;
[ 1, 4, 9, 16, 25, 36, 49, 64, 81, 100 ]

and you now want to compute a list of cubes.

First you press <ctr>-'P' six times (or <ctr>-'U'/'6'/<ctr>-'P') to go
back to the line 'e := 2;;'.  Then you change this line to 'e := 3;;'.
Next you press <enter> to enter this line.

If you now press <ctr>-'N', it goes to the next line in the history,
starting from the one you just entered, i.e., it immediately brings up
the next line 'l := [];;'.  Again you press <enter> to enter this line
and <ctr>-'N' to bring up the next line 'for i in [1..10] do'.
Four more <enter>/<ctr>-'N' later you have reentered the whole block.

<ctr>-'O' is simply a shorthand for <enter>/<ctr>-'N'.  Thus instead of
pressing <enter>/<ctr>-'N' six times you can simply press <ctr>-'O' six
times.  Or, even shorter, you can simply press '<ctr>-'U'/'6'/<ctr>-'O'.

Try it.  It is much simpler to use than to describe.
And to reenter large blocks of code it is very useful.

Martin.

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



From a.mathas@ic.ac.uk Sat Mar  9 12:30:05 1996
Date:           Sat, 09 Mar 96 12:30:05 +0000
From:           "Andrew Mathas" <a.mathas@ic.ac.uk>
Subject:        Specht 2.0

Dear Ms and Mr Gap:

I have just uploaded the new version of my package for calculating
decomposition numbers of Hecke algebras, q-Schur algebras, and symmetric
groups to samson.math.rwth-aachen.de; it can be found in the incoming
directory as specht-2.0.tar.gz. The package can also be obtained via the
www at
  http://www.ma.ic.ac.uk/~apmath/abstracts/specht.html
Below I include the README file for your perusal.

Best regards,
     Andrew Mathas

----
A mathematician is a device for turning coffee into theorems.


------------------------------------------------------
SPECHT 2.0                                  March 1996
    A package for calculating decomposition numbers of
    Hecke algebras of the symmetric groups and q-Schur
    algebras.

(C) Andrew Mathas  a.mathas@ic.ac.uk  Imperial College
------------------------------------------------------


For installation notes see below. What follows is a brief
description of the package; more details can be found in
the manual, a postscript version of which can be found
in specht.ps.

Specht is a GAP share library package; it is made available
only under the usual terms and conditions of GAP.

Andrew Mathas
London March 1996


Description:
------------

This package contains functions for computing the decomposition matrices
for Hecke algebras of the symmetric groups. As the (modular)
representation theory of these algebras closely resembles that of the
(modular) representation theory of the symmetric groups --- indeed, the
later is a special case of the former --- many of the combinatorial tools
from the representation theory of the symmetric group are included in
this package.

These programs grew out of the attempts by Gordon James and myself [JM1]
to understand the decomposition matrices of Hecke algebras of type *A*
when $<q>=-1$. The package is now much more general and its\'\ highlights
include\:

  1. \Specht\ provides a means of working in the Grothendieck ring of a
Hecke algebra <H> using the three natural bases corresponding to the
Specht modules, projective indecomposable modules, and simple modules.

  2. For Hecke algebras defined over fields of characteristic zero we
have implemented the algorithm of Lascoux, Leclerc, and Thibon [LLT] for
computing decomposition numbers and ``crystallized decomposition
matrices\'\'. In principle, this gives all of the decomposition matrices
of Hecke algebras defined over fields of characteristic zero.

  3. We provide a way of inducing and restricting modules. In addition,
it is possible to ``induce\'\'\ decomposition matrices; this function is
quite effective in calculating the decomposition matrices of Hecke
algebras for small <n>.

  4. The <q>--analogue of Schaper\'s theorem [JM] is included, as is
Kleshchev\'s [K] algorithm of calculating the Mullineux map. Both are
used extensively when inducing decomposition matrices.

  5. \Specht\ can be used to compute the decomposition numbers of
<q>--Schur algebras (and the general linear groups), although there is
less direct support for these algebras. The decomposition matrices for the
<q>--Schur algebras defined over fields of characteristic zero for $n\<11$
and all <e> are included in \Specht.

  6. The Littlewood--Richard rule, its inverse, and functions for many
of the standard operations on partitions (such as calculating cores,
quotients, and adding and removing hooks), are included.

  7. The decomposition matrices for the symmetric groups $\Sym_n$ are
included for $n\<15$ and for all primes.


Installation:
-------------

When you unpack Specht you should find the following files
  README      -this file
  init.g      -GAP source
  specht.g
  symmcomb.g
  tableaux.g
  tex.g
  lib/        -Specht library files
  specht.ps   -postscript version of Specht manual
  specht.tex  -LaTeX version of Specht manual

Ideally, Specht should be installed in GAP the packages directory,
however, it can be installed anywhere. Once the files have been
placed in the desired directory edit the file <init.g> and set
the variable 'SPECHTHOME' to the name of the current directory.
Usually, this will be something like:
  SPECHTHOME:="/usr/local/lib/gap/pkg/specht/";
(which is the default).

Specht is now installed and ready to use\:
|gap> RequirePackage("specht");
gap> H:=Specht(3);
Specht(e=3, S(), P(), D(), Pq())|

The online documentation can be installed by first copying
  specht.tex
into the GAP doc/ directory, adding the line
  \Include{specht}
to the end of <manual.tex>, and then re-LaTeXing the manual.



From gaehler@orphee.polytechnique.fr Mon Mar 11 17:50:57 1996
Date:           Mon, 11 Mar 96 17:50:57 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        GraphicLattice for Conjugacy Classes?

Dear GAP Forum:

I have been experimenting with XGAP, and I am very impressed how easy
it is to extract information about subgroups and the subgroup structure
of a group. However, with larger groups the Hasse diagram returned by
GraphicLattice quickly becomes very complicated. One possible solution
to this problem is to look at sublattices by means of InteractiveLattice.

I would like to suggest an other solution here, which might be provided
as a further option. The Hasse diagram would often be greatly simplified
if vertices belonging to the same conjugacy class of subgroups could be
merged. Vertices would then correspond to conjugacy classes of subgroups,
and two vertices would be connected if one conjugacy class contains
subgroups having maximal subgoups in the other conjugacy class. Having
such a graph, one could then still inquire (with the right mouse button
menu) about properties of subgroups which are class functions.

In XGAP library file glatlist.g it is claimed that:

##  'GraphicLattice( <rec>[, <x>, <y>][, "prime"] )
##  ------------------------------------------------
##
##  'GraphicLattice' draws the lattice described by a record containing:
##
##  'vertices':
##    a list of objects
##
##  'classPositions':
##    A pair '[<c>,<p>]', where <c> is a class number and <p> is the position
##    in this  class    meaning  that  vertex number    <i>   lies in   class
##    'classes[<i>][1]' at position 'classes[<i>][2]'.
##
##  'sizes':
##    a list of sizes
##
##  'maximals':
##    a list of maximals
##
##  an example
##  ----------
##
##  MyLattice := rec(
##    vertices := [ 1 .. 7 ],
##    maximals := [ [3], [3], [4,6,7], [], [], [5], [] ],
##    classPositions := [ [1,1], [2,1], [3,1], [4,1], [5,1], [6,1], [4,2] ]
##  );

Well, I tried it. I also added a further record field called sizes,
which is mentioned elsewhere, and which makes the graph much nicer.
It almost works, but not quite. Here is an example:

   a5:=AlternatingGroup(5);
   l:=Lattice(a5);;
   SetPrintLevel(l,2); l;

   vert:=List(l.classes, x -> x.representative);

   # I take the first representative in each conjugacy class
   pos:=[]; for i in [1..Length(vert)] do Add(pos,[i,1]); od;

   drop:=function(x)
     if Length(x)=0 then return x; else return List(x,y->y[1]); fi;
   end;
   max:=List(List(l.maximalSubgroups,drop),z->Set(z));

   sz:=List([1..Length(vert)],z->Size(l.classes[z].representative));

   lat:=rec(vertices:=vert, maximals:=max, classPositions:=pos, sizes:=sz);

Upon calling GraphicLattice, after drawing the vertices XGAP stalls:

gap> GraphicLattice(lat);
Error, String: cannot convert function ( obj )
    Print( obj.name );
end into a string in
String( record.(nam) ) called from
StringRec( obj ) called from
String( record.(nam) ) called from
StringRec( obj ) called from
String( record.(nam) ) called from
...
brk> quit;

If I set lat.vertices:=[1..Length(l.classes)]; and call GraphicLattice(lat)
again, I get a nice graph - but that's it. Of course, since vertices now
correspond just to numbers, there is not much to inquire about them.
However, I also cannot relable the vertices, because that menu option
is missing.

It is most likely that I have been abusing features that are not yet
official or not yet finished, but here is my question anyway:

How can I tweak the records read by GraphicLattice (and which are these?)
so that all information GraphicLattice needs is there, and the initial
graph is displayed? And what can I do that the usual menus are enabled
so that I can relabel vertices, and inquire about properties of a subgroup
a vertex points to?

If this is not feasible in the present version, I hope that at least
in some future version I can type something like

GraphicLattice(g, "ConjugacyClasses");

and, perhaps,

InteractiveLattice(g, "ConjugacyClasses");


Best regards,

Franz G"ahler



From gaehler@orphee.polytechnique.fr Mon Mar 11 17:49:21 1996
Date:           Mon, 11 Mar 96 17:49:21 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        Errors in manual

Dear GAP Forum:

When trying to implement a new kind of group elements, I came across
some errors (all related) in the manual in chapters 1.28, 1.29 and 1.30.
In these chapters, binary operations carry names such as ...Ops.'in',
...Ops.'*', ..Ops.'<', etc., where these should rather be ...Ops.\in,
...Ops.\*, ...Ops.\<, etc.

Regards, Franz G"ahler



From frank.celler@math.rwth-aachen.de Tue Mar 12 14:44:49 1996
Date:           Tue, 12 Mar 96 14:44:49 +0000
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        XGAP

Dear GAP Forum,

Franz G"ahler wrote:

> I would like to suggest an other solution here, which might be provided
> as a further option. The Hasse diagram would often be greatly simplified
> if vertices belonging to the same conjugacy class of subgroups could be
> merged. Vertices would then correspond to conjugacy classes of subgroups,

Goetz Pfeiffer has an experimental version to display the table
of marks, but it requires some changes to make it compatible with
version 1.3 of XGAP.

The main task which has to be done is to update and extend "gatlist.g",
which - as you have remarked - is neither in the manual nor yet finished.
I want to make some functions which will allow you to define your
own "type" of lattice and set of functions to manipulate the vertices.
It would then be rather easy to adapt Goetz's TOM lattice.

> If this is not feasible in the present version, I hope that at least
> in some future version I can type something like
>
> GraphicLattice(g, "ConjugacyClasses");
>
> and, perhaps,
>
> InteractiveLattice(g, "ConjugacyClasses");

At least the table of marks lattice should be ready in one or two month.
I cannot say how long it will take to finish "glatlist.g" and make it
an offical part of XGAP.

best wishes
  Frank



From gaehler@orphee.polytechnique.fr Wed Mar 13 14:50:11 1996
Date:           Wed, 13 Mar 96 14:50:11 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        Re: GraphicLattice for Conjugacy Classes?

Dear GAP Forum:

Regarding my problem with a graphic lattice for conjugacy classes
of subgroups, I see now much clearer. I still don't know why XGAP
stalls on my example, but I realize now that GraphicLatticeRecord
is invoked, and for GraphicLatticeRecord no mouse button menus
are installed, and nor is the relabel entry in the CleanUp menu.
So without additional programming GraphicLatticeRecord won't do
the job. Meanwhile, I found a different solution, however.

I have modified my copy of XGAP library file glatgrp.g.
Routine GroupOps.GraphicLattice now checks for the presence of an
optional argument "conjugacy classes". If present, it sets the
operations record of the sheet it returns to ConjugacyClassLatticeOps,
instead of GraphicLatticeOps. ConjugacyClassLatticeOps basically is
a copy of GraphicLatticeOps, except for three routines which I have
modified:

1) In ConjugacyClassLatticeOps.MakeLattice, I set all class lengths to 1:

   sheet.init.classLengths := List( sheet.classes, x -> 1 );

2) In ConjugacyClassLatticeOps.MakeMenus, the subgroups menu is NOT
   installed, as its use is potentially dangerous. It could be added
   again after the routines it calls have been adapted to the new
   situation (e.g., when asking for the normalizer of a conjugacy
   class of subgroups, return the conjugacy class of the normalizer
   of any representative).

3) The routine ConjugacyClassLatticeOps.MakeMaximalSubgroups has been
   rewritten. It returns the initial setup for the ConjugacyClassLattice:

ConjugacyClassLatticeOps.MakeMaximalSubgroups := function ( sheet )
    local   maxs,               # maximals (result)
            lat,                # lattice
            rel,                # maximal subgroup relation (for reps)
            rep,                # representative of a class
            reps,               # representatives of classes
            i;                  # loop variable

    # get the maximals relation
    lat := sheet.lattice;
    rel := lat.operations.MaximalSubgroups( lat );

    # now construct the maximals relation for conjugacy classes
    # class 1 (trivial subgroup) has no maximals
    for i in [2..Length(lat.classes)] do
        rel[i] := Set( List( rel[i], pair -> pair[1] ) );
    od;

    # construct the initial setup
    maxs := [];
    for i  in [ 1 .. Length(lat.classes) ]  do
        rep := lat.classes[i].representative;
        maxs[i] := [ i, Size( rep ), rel[i], i, 1];
    od;
    reps := [1..Length(lat.classes)];

    # assign the result
    sheet.init.vertices := maxs;
    sheet.init.reps     := reps;
end;


This solution works quite nicely. If there is interest, I'd be happy
to make the details of my modifications available. Perhaps the
developers wish to include the new option in the official version -
provided my modifications do not cause any unwanted side effects,
which I might have overlooked.

Best regards,

Franz G"ahler



From frank.celler@math.rwth-aachen.de Thu Mar 14 10:58:26 1996
Date:           Thu, 14 Mar 96 10:58:26 +0000
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        Graphic Lattice for ConjugacyClasses

Dear GAP Form, dear Franz G"ahler,

you wrote:

> This solution works quite nicely. If there is interest, I'd be happy
> to make the details of my modifications available. Perhaps the

why not put it on our ftp server?  As you wrote it would be nice to be able
to have some subgroup functions working and I would like to be able to see
how many subgroups of a conjugacy class are contained in a representative
and in how many subgroups of class a representative is contained in.  But I
am sure that even the basic solution is quite useful, so it would be nice if
you put a patch file into

    ftp://ftp.math.rwth-aachen.de/pub/incoming

The other extensions require some more work, and if you want to extend
your modifications into this direction,  please contact

    gap-trouble@math.rwth-aachen.de

and we can sort out the details.

with kind regards
  Frank



From hoppe@math.tu-berlin.de Thu Mar 14 20:07:03 1996
Date:           Thu, 14 Mar 96 20:07:03 +0100
From:           "Andreas Hoppe" <hoppe@math.tu-berlin.de>
Subject:        Untergruppengraphen

Dear gap-forum,
ich suche fuer die transitiven Gruppen vom Grad 12 eine Funktion, die
mir graphisch darstellt, wie die einzelnen Untergruppen der S12 in-
einander enthalten sind.

Katharina Geissler



From alexander.hulpke@math.rwth-aachen.de Fri Mar 15 14:22:54 1996
Date:           Fri, 15 Mar 96 14:22:54 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: Errors in manual

Dear GAP Forum:

Franz G"ahler wrote:

> When trying to implement a new kind of group elements, I came across
> some errors (all related) in the manual in chapters 1.28, 1.29 and 1.30.
> In these chapters, binary operations carry names such as ...Ops.'in',
> ...Ops.'*', ..Ops.'<', etc., where these should rather be ...Ops.\in,
> ...Ops.\*, ...Ops.\<, etc.

These errors stem from former versions of GAP when this notation was
permitted. When the new concept of strings as lists of characters was
introduced in version 3.3, the notation had to be changed to \<
&c. to avoid misinterpretations by the parser.
Thanks for pointing out this error. We will fix the manual in the next
version.
We apologize for problems this might have caused.

Alexander Hulpke



From alexander.hulpke@math.rwth-aachen.de Fri Mar 15 14:38:08 1996
Date:           Fri, 15 Mar 96 14:38:08 +1553
From:           "Alexander Hulpke" <Alexander.Hulpke@Math.RWTH-Aachen.DE>
Subject:        Re: Subgroup Lattices (Untergruppengraphen)

Dear GAP-Forum,

Katharina Geissler wrote: (translation by me)

> I'm searching a function for the transitive groups of degree 12 to display
> how the several subgroups of S12 are contained within each other.

What you're asking for are actually two things. The second is a graphical
display. In principle you could persuade 'GraphicLattice' to display a
partial lattice for the transitive groups. See the ongoing discussion about
XGAP and its possible extensions. We are currently discussing several
possibilities, but so far nothing specific has been planned.
Nevertheless I doubt that this is what you really want, unless you have a
BIG monitor: there are 301 transitive groups of degree 12. Displaying all
containments of conjugates will probably result in a mess of lines on the
screen which is not really usable. Anyhow, if you're using pen and paper you
could still try to produce such a picture based on the information you would
provide to 'GraphicLattice'. (BTW.: If you finally get such a picture I
would be VERY interested to get a copy of it. So far I've been too lazy
to do it myself.)

The first (and bigger) problem is to get the actual containment information.
So far there is no function to compute this with a single command in GAP.
I will describe, however,  how you can compute it yourself, but it might
take you some time to do so:

The process will yield not only information *whether* a group is contained
in another, but also information how many conjugacy classes exist if the
subgroup is maximal. (You will need this information if you want to identify
Galois groups, as I suppose. You should note as well, that GAP already
contains information about resolvents distinguishing the groups. Probably
this is of help. Write to me directly if you want more information about this.)

If you can compute representatives of the conjugacy classes of maximal
subgroups of each transitive group, you are done. Non-maximal containment
simply follows by induction. 265 of the transitive groups are solvable. By
converting them to an AgGroup and then to a SpecialAgGroup, you can compute
representatives of the conjugacy classes of maximal subgroups and
transfer them (using the components .bijection in the SAgGroup and the
AgGroup) back in the permutation group. There, you select the ones which are
transitive. The command 'TransitiveIdentification' then tells you for each
of the representatives the number in the list of transitive groups, avoiding
conjugacy tests in S12.

This leaves 36 non-solvable groups. Coping with S12 and A12 is quite simple,
as the maximal subgroups are classified already (the imprimitive ones are
wreath products, the primitive ones are dealt with in the ATLAS).
8 of the remaining groups are wreath products. I have procedures to get
representatives of the conjugacy classes of transitive subgroups for these
groups, that I can provide to you if you want. However, it is not hard to
classify their maximal subgroups.
Of the remaining 26 groups, 18 are of size smaller 10000. You can use the
subgroup lattice program to get their maximal subgroups.
Most of the other groups are normal of small index in a wreath product.
Using this information one can describe the transitive subgroups of them.
(Again, I have functions to deal with this case. Write to me if you want
further information.)
Remaining is M12, whose maximal subgroups are given in the ATLAS.
In all these cases, after getting the maximal subgroups, treatment is the
same as in the solvable case.

Going through this process is a tour de force. However I can't imagine an
easier way (except persuading someone else to do it, but that's exactly
what I'm doing here).

I hope this helps. If anything in my description is unclear please ask.

Alexander Hulpke

-- Lehrstuhl D fuer Mathematik, RWTH, Templergraben 64, 52056 Aachen, Germany,
eMail: Alexander.Hulpke@math.rwth-aachen.de



From martin.schoenert@math.rwth-aachen.de Fri Mar 15 14:59:00 1996
Date:           Fri, 15 Mar 96 14:59:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        BUGFIX 03 (Guava external programs)

    This mail contains a bugfix for a serious problem in GAP 3.4.3.
    You should apply this bugfix soon if you are using Guava.
    The problem is in the external programs of Guava, and may cause the
    Guava functions 'ConstantWeightSubcode', 'AutomorphismGroup', and
    'CodeIsomorphism', to fail with cryptic error messages on some machines.


HOW TO APPLY

    The problem is a serious problem, because if may cause a computation to
    fail.  Thus the bugfix has medium priority, and we recommend that you
    apply it soon if you are using Guava.

    Go to the GAP directory (the directory with the 'lib/' subdirectory),
    name this file 'bugfix03.dif', and issue the command:

        patch -p0 < bugfix03.dif

    To recompile the external programs of Guava afterwards,
    go to the 'pkg/guava/' subdirectory and issue the command:

        make


VERSION

    GAP 3.4.3.0


DESCRIPTION

    The Guava functions 'ConstantWeightSubcode', 'AutomorphismGroup', and
    'CodeIsomorphism' fail with cryptic error messages on some machines.


CORRECT BEHAVIOUR

gap> RequirePackage("guava");
gap> C := HammingCode( 3 );
a linear [7,4,3] Hamming (3,2) code over GF(2)
gap> AutomorphismGroup( C );
Group( (1,2)(5,6), (2,4)(3,5), (2,3)(6,7), (4,6)(5,7), (4,5)(6,7) )


COMMENT

    The include file 'group.h' defined 'MAX_NAME_LENGTH', which is the
    maximal length of the names of the input and output files for the
    external programs, to be 16.  This is too short if those files are
    stored in '/var/tmp/'.  This bugfix raises 'MAX_NAME_LENGTH' to 64.


PATCH

--- pkg/guava/src/leon/src/group.h      Sat Sep 19 02:08:02 1992
+++ pkg/guava/src/leon/src/group.h      Thu Jan  4 12:58:48 1996
@@ -116,7 +116,7 @@
 #endif

 #ifndef MAX_NAME_LENGTH
-#define MAX_NAME_LENGTH      16
+#define MAX_NAME_LENGTH      64
 #endif

 #ifndef MAX_FILE_NAME_LENGTH
END OF  bugfix03.dif ________________________________________________________



From martin.schoenert@math.rwth-aachen.de Fri Mar 15 14:59:00 1996
Date:           Fri, 15 Mar 96 14:59:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        BUGFIX 04 ('SimplifyPresentation')

    This mail contains a bugfix for two dangerous problems in GAP 3.4.3.
    Note that bugfix01 already provided a workaround for these problems.
    The problems are in 'TzFindCyclicJoins' for presentations of groups,
    and may cause 'FpGroup' (when called for subgroups of finitely
    presented groups), 'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo',
    and 'TzGoGo' to produce incorrect presentations without a warning.


HOW TO APPLY

    Note that bugfix01 already provided a workaround for these problems.
    Thus the priority of this bugfix is low.

    Before applying this bugfix you *must* already have applied bugfix01.
    Go to the GAP directory (the directory with the 'lib/' subdirectory),
    name this file 'bugfix04.dif', and issue the command:

        patch -p0 < bugfix04.dif

    This bugfix changes only the library.  Thus you need not recompile the
    GAP kernel.


VERSION

    GAP 3.4.3.1


DESCRIPTION

    'TzFindCyclicJoins', which is is called directly or indirectly from
    'FpGroup' (when called for subgroups of finitely presented groups),
    'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo', and 'TzGoGo',
    may produce incorrect presentations.


CORRECT BEHAVIOUR

gap> G := FreeGroup( 3 );
Group( f.1, f.2, f.3 )
gap> a := G.generators[1];;
gap> b := G.generators[2];;
gap> c := G.generators[3];;
gap> G.relators := [
>   a^7, c^4,
>   Comm( a,b ), Comm( a,c ), Comm( b,c ),
>   c * c * a * a * a * c * a ];;
gap>
gap> P := PresentationFpGroup( G );;
gap> SimplifyPresentation( P );
#I  there are 3 generators and 6 relators of total length 30
#I  there are 2 generators and 4 relators of total length 37
#I  there are 1 generator and 0 relators of total length 0
gap>
gap> P;
<< presentation with 1 gens and 0 rels of total length 0 >>


DESCRIPTION

    'TzFindCyclicJoins', which is is called directly or indirectly from
    'FpGroup' (when called for subgroups of finitely presented groups),
    'SimplifyPresentation', 'SimplifiedFpGroup', 'TzGo', and 'TzGoGo',
    may signal

        Error: Integer operations: <divisor> must be nonzero.


CORRECT BEHAVIOUR

gap> K := FreeGroup(8);
Group( f.1, f.2, f.3, f.4, f.5, f.6, f.7, f.8 )
gap> g1 := K.generators[1];;
gap> g2 := K.generators[2];;
gap> g3 := K.generators[3];;
gap> g4 := K.generators[4];;
gap> g5 := K.generators[5];;
gap> g6 := K.generators[6];;
gap> g7 := K.generators[7];;
gap> g8 := K.generators[8];;
gap> K.relators :=
> [ g1^2*g8^-1*g4^-1, g2^2, g3^2, g4^3, g5^3, g6^2*g8^-1, g7^2*g8^-1, g8^2,
>   g2^-1*g1^-1*g2*g1*g5^-2*g4^-1, g3^-1*g1^-1*g3*g1*g2^-1, g4^-1*g1^-1*g4*g1,
>   g5^-1*g1^-1*g5*g1*g5^-1, g6^-1*g1^-1*g6*g1, g7^-1*g1^-1*g7*g1*g8^-1,
>   g8^-1*g1^-1*g8*g1, g3^-1*g2^-1*g3*g2, g4^-1*g2^-1*g4*g2*g4^-1,
>   g5^-1*g2^-1*g5*g2*g5^-1, g6^-1*g2^-1*g6*g2, g7^-1*g2^-1*g7*g2,
>   g8^-1*g2^-1*g8*g2, g4^-1*g3^-1*g4*g3*g5^-1*g4^-2,
>   g5^-1*g3^-1*g5*g3*g5^-2*g4^-1, g6^-1*g3^-1*g6*g3, g7^-1*g3^-1*g7*g3,
>   g8^-1*g3^-1*g8*g3, g5^-1*g4^-1*g5*g4, g6^-1*g4^-1*g6*g4, g7^-1*g4^-1*g7*g4,
>   g8^-1*g4^-1*g8*g4, g6^-1*g5^-1*g6*g5, g7^-1*g5^-1*g7*g5, g8^-1*g5^-1*g8*g5,
>   g7^-1*g6^-1*g7*g6*g8^-1, g8^-1*g6^-1*g8*g6, g8^-1*g7^-1*g8*g7 ];;
gap>
gap> P := PresentationFpGroup( K );;
gap> SimplifyPresentation( P );
#I  there are 4 generators and 17 relators of total length 122
#I  there are 4 generators and 13 relators of total length 84
#I  there are 4 generators and 12 relators of total length 74
gap>
gap> P;
<< presentation with 4 gens and 12 rels of total length 74 >>


COMMENT

    This bugfix replaces the faulty function 'TzFindCyclicJoins' by a
    corrected one.

    'TzFindCyclicJoins' has the following purpose.  If the presentation being
    simplified contains a commutator relator 'Comm(<a>,<b>)' and at least one
    power relator of the form '<a>^<n>' or '<b>^<m>', where <a> and <b> are
    generators or inverses of generators, then the subroutine searches for
    further relators which are words in <a> and <b> and their inverses only,
    and then it tries to reduce these relators by applying the Euclidean
    algorithm to the occurring exponents.

    The fact that this bug has been discovered only now in a routine which is
    being used since 1993 seems to indicate that it only occurs in rather
    rare situations.  Unfortunately, however, it is one of those nasty bugs
    which may produce wrong results without giving any evidence of that fact.
    Therefor we strongly recommend that you implement this bugfix in your
    local GAP installation.


PATCH

Prereq: 3.4.1.3
--- lib/fptietze.g      1996/02/16 09:58:00
+++ lib/fptietze.g      1996/03/12 14:03:41
@@ -2,7 +2,7 @@
 ##
 #A  fptietze.g                GAP library                      Volkmar Felsch
 ##
-#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
+#A  @(#)$Id: forum96a.txt,v 1.1 1997/04/06 10:38:29 gap Exp $
 ##
 #Y  Copyright 1990-1992,  Lehrstuhl D fuer Mathematik,  RWTH Aachen,  Germany
 ##
@@ -10,6 +10,9 @@
 ##  finitely presented groups.
 ##
 #H  $Log: forum96a.txt,v $
 #H  Revision 1.1  1997/04/06 10:38:29  gap
 #H  Added forum archives (ahulpke)
 #H
+#H  Revision 3.4.1.4  1996/03/12  14:03:41  vfelsch
+#H  corrected bugs in TzFindCyclicJoins
+#H
 #H  Revision 3.4.1.3  1996/02/16  09:58:00  vfelsch
 #H  commented out the call of TzFindCyclicJoins which contains a bug
 #H
@@ -1137,9 +1140,9 @@
 ##
 TzFindCyclicJoins := function ( T )

-    local e, exp, exponents, fac, flags, gen, gens, i, invs, j, k, l, length,
-          lengths, n, next, num, numgens, numrels, ggt, rel, rels, T, tietze,
-          word;
+    local e, exp, exponents, fac, flags, gen, gens, ggt, i, invs, j, k, l,
+          length, lengths, n, newstart, next, num, numgens, numrels, prev,
+          powers, rel, rels, T, tietze, word;

     if T.printLevel >= 3 then
         Print( "#I  searching for cyclic joins\n" );
@@ -1147,117 +1150,142 @@

     # check the given argument to be a Tietze record.
     TzCheckRecord( T );
-
-    # Try to find exponents for the generators.
-    exponents := TzGeneratorExponents( T );
     tietze := T.tietze;
     tietze[TZ_MODIFIED] := false;

-    if Sum( exponents ) = 0 then  return;  fi;
-
-    # initialize some local variables.
-    gens := tietze[TZ_GENERATORS];
-    numgens := tietze[TZ_NUMGENS];
-    rels := tietze[TZ_RELATORS];
-    numrels := tietze[TZ_NUMRELS];
-    lengths := tietze[TZ_LENGTHS];
-    invs := tietze[TZ_INVERSES];
-    flags := tietze[TZ_FLAGS];
-
-    # Now work off all commutator relators of length 4.
-    i := 1;
-    while i <= numrels do
+    # start the routine and repeat it whenever a generator has been
+    # eliminated.
+    newstart := true;
+    while newstart do
+
+      # try to find exponents for the generators.
+      exponents := TzGeneratorExponents( T );
+      if Sum( exponents ) = 0 then  return;  fi;
+
+      # initialize some local variables.
+      newstart := false;
+      gens := tietze[TZ_GENERATORS];
+      numgens := tietze[TZ_NUMGENS];
+      rels := tietze[TZ_RELATORS];
+      numrels := tietze[TZ_NUMRELS];
+      lengths := tietze[TZ_LENGTHS];
+      invs := tietze[TZ_INVERSES];
+      flags := tietze[TZ_FLAGS];
+
+      # now work off all commutator relators of length 4.
+      i := 0;
+      while i < numrels do

+        # find the next commutator.
+        i := i + 1;
         rel := rels[i];
         if lengths[i] = 4 and rel[1] = invs[numgens+1+rel[3]] and
-            rel[2] = invs[numgens+1+rel[4]] then
-
-            # There is a commutator relator of the form [a,b]. Check if
-            # there are also power relators of the form a^m or b^n.
+          rel[2] = invs[numgens+1+rel[4]] then

-            num := [ AbsInt( rel[1] ), AbsInt( rel[2] ) ];
-            exp := [ exponents[num[1]], exponents[num[2]] ];
+          # There is a commutator relator of the form [a,b]. Check if
+          # there are also power relators of the form a^m or b^n.

-            # If there is at least one relator of the form a^m or b^n, then
-            # search for a relator of the form  a^s * b^t  (modulo [a,b])
-            # with s prime to m or t prime to n, respectively. For, if s is
-            # prime to m, then we can use the Euclidian algorithm to
-            # express a as a power of b and then eliminate a.
-
-            if exp[1] > 0 or exp[2] > 0 then
-
-                j := 0;  while j < numrels do
-                   j := j + 1;
-                   if lengths[j] > 0 and j <> i then
-                      rel := rels[j];
-                      length := lengths[j];
-                      e := [0, 0];
-                      n := 0;
-                      l := 0;  while l < length do
-                         l := l + 1;
-                         next := rel[l];
-                         if next = num[1] then  e[1] := e[1] + 1;
-                         elif next = num[2] then  e[2] := e[2] + 1;
-                         elif next = -num[1] then  e[1] := e[1] - 1;
-                         elif next = -num[2] then  e[2] := e[2] - 1;
-                         else  e := [0, 0];  l := length;
-                         fi;
-                      od;
+          num := [ AbsInt( rel[1] ), AbsInt( rel[2] ) ];
+          exp := [ exponents[num[1]], exponents[num[2]] ];
+          fac := [ 0, 0 ];
+          e   := [ 0, 0 ];
+
+          # If there is at least one relator of the form a^m or b^n, then
+          # search for a relator of the form  a^s * b^t  (modulo [a,b])
+          # with s prime to m or t prime to n, respectively. For, if s is
+          # prime to m, then we can use the Euclidian algorithm to
+          # express a as a power of b and then eliminate a.
+
+          if exp[1] > 0 or exp[2] > 0 then
+
+             j := 0;
+             while j < numrels do
+
+                # get the next relator.
+                j := j + 1;
+                if lengths[j] > 0 and j <> i then
+                   rel := rels[j];
+
+                   # check whether rel is a word in a and b.
+                   length := lengths[j];
+                   e[1]   := 0;
+                   e[2]   := 0;
+                   powers := 0;
+                   prev   := 0;
+                   l      := 0;
+                   while l < length do
+                      l := l + 1;
+                      next := rel[l];
+                      if next <> prev then
+                         powers := powers + 1;
+                         prev := next;
+                      fi;
+                      if next = num[1] then  e[1] := e[1] + 1;
+                      elif next = num[2] then  e[2] := e[2] + 1;
+                      elif next = -num[1] then  e[1] := e[1] - 1;
+                      elif next = -num[2] then  e[2] := e[2] - 1;
+                      else l := length + 1;
+                      fi;
+                   od;

-                      if e[1] <> 0 or e[2] <> 0 then
+                   if l = length and powers > 1 then

-                         # reduce exponents, if possible.
-                         fac := [ num[1], num[2] ];
-                         for k in [ 1, 2 ] do
-                            if e[k] < 0 then
-                               fac[k] := invs[numgens+1+k];
-                               e[k] := - e[k];
+                      # reduce exponents, if possible.
+                      for k in [ 1, 2 ] do
+                         fac[k] := num[k];
+                         if exp[k] > 0 then
+                            e[k] := e[k] mod exp[k];
+                            if e[k] > exp[k]/2 then
+                               e[k] := exp[k] - e[k];
+                               fac[k] := - fac[k];
                             fi;
-                            if e[3-k] = 0 or exp[3-k] > 0 and
-                               e[3-k] mod exp[3-k] = 0 then
-                               e[k] := GcdInt( exp[k], e[k] );
-                               if e[k] < exp[k] then
-                                  exp[k] := e[k];
-                                  exponents[num[k]] := exp[k];
-                                  AddRelator( T, gens[num[k]]^exp[k] );
-                                  numrels := tietze[TZ_NUMRELS];
-                                  tietze[TZ_MODIFIED] := true;
-                               fi;
-                            fi;
-                         od;
+                         elif e[k] < 0 then
+                            e[k] := - e[k];
+                            fac[k] := - fac[k];
+                         fi;
+                         if fac[k] < 0 then
+                            fac[k] := invs[numgens+1-fac[k]];
+                         fi;
+                      od;

-                         # reduce the curent relator, if possible.
-                         if e[1] > 0 and e[2] > 0 and e[1] + e[2] < length
-                            then
-                            e[1] := e[1] mod exp[1];
-                            e[2] := e[2] mod exp[2];
-                            rel := [ ];
-                            if e[1] > 0 then  rel := Concatenation(
-                               rel, fac[1] + 0 * [1..e[1]] );
-                            fi;
-                            if e[2] > 0 then  rel := Concatenation(
-                               rel, fac[2] + 0 * [1..e[2]] );
-                            fi;
-                            rels[j] := rel;
-                            lengths[j] := e[1] + e[2];
-                            tietze[TZ_TOTAL] := tietze[TZ_TOTAL] - length
-                               + e[1] + e[2];
-                            flags[i] := 1;
-                            tietze[TZ_MODIFIED] := true;
-                            if T.printLevel >= 3 then  Print(
-                               "#I  rels[",j,"] reduced to ",rels[j],"\n" );
+                      # now the e[k] are non-negative.
+                      for k in [ 1, 2 ] do
+                         if e[k] > 0 and e[3-k] = 0 then
+                            exp[k] := GcdInt( e[k], exp[k] );
+                            if exp[k] <> exponents[num[k]] then
+                               exponents[num[k]] := exp[k];
+                               e[k] := exp[k];
                             fi;
                          fi;
+                      od;

-                         # try to find a generator that can be deleted.
-                         if e[2] = 1 then  n := num[2];
-                         elif e[1] = 1 then  n := num[1];
+                      # reduce the current relator, if possible.
+                      if e[1] + e[2] < length or powers > 2 then
+                         rel := [ ];
+                         if e[1] > 0 then  rel := Concatenation(
+                            rel, fac[1] + 0 * [1..e[1]] );
+                         fi;
+                         if e[2] > 0 then  rel := Concatenation(
+                            rel, fac[2] + 0 * [1..e[2]] );
                          fi;
+                         rels[j] := rel;
+                         lengths[j] := e[1] + e[2];
+                         tietze[TZ_TOTAL] := tietze[TZ_TOTAL] - length
+                            + lengths[j];
+                         flags[j] := 1;
+                         tietze[TZ_MODIFIED] := true;
+                         if T.printLevel >= 3 then  Print(
+                            "#I  rels[",j,"] reduced to ",rels[j],"\n" );
+                         fi;
+                      fi;

+                      # try to find a generator that can be deleted.
+                      if e[1] = 1 then  n := num[1];
+                      elif e[2] = 1 then  n := num[2];
+                      else n := 0;
                          for k in [ 1, 2 ] do
                             if n = 0 and e[k] > 1 and
-                               GcdInt( e[k],exp[k] ) = 1
-                               then
+                               GcdInt( e[k], exp[k] ) = 1 then
                                ggt := Gcdex( e[k], exp[k] );
                                gen := [gens[num[1]], gens[num[2]]];
                                if fac[1] < 0 then  gen[1] := gen[1]^-1;  fi;
@@ -1270,20 +1298,22 @@
                          od;
                       fi;

-                      if n <> 0 then
-                         TzEliminate( T, gens[n] );
-                         numgens := tietze[TZ_NUMGENS];
-                         numrels := tietze[TZ_NUMRELS];
-                         invs := tietze[TZ_INVERSES];
+                      # eliminate a generator if it is possible and allowed.
+                      if n <> 0 and T.generatorsLimit < numgens then
+                         TzEliminate( T );
                          tietze[TZ_MODIFIED] := true;
                          j := numrels;
-                         i := 0;
+                         i := numrels;
+                         if TZ_NUMGENS < numgens then
+                            newstart := true;
+                         fi;
                       fi;
                    fi;
-                od;
-            fi;
+                fi;
+             od;
+          fi;
         fi;
-        i := i + 1;
+      od;
     od;

     if tietze[TZ_MODIFIED] then
@@ -1318,8 +1348,6 @@
     fi;
     tietze := T.tietze;

-    tietze[TZ_MODIFIED] := false;
-
     numgens := tietze[TZ_NUMGENS];
     rels := tietze[TZ_RELATORS];
     numrels := tietze[TZ_NUMRELS];
@@ -1415,11 +1443,11 @@

     # try to find cyclic subgroups by looking at power and commutator
     # relators.
-    ## if tietze[TZ_TOTAL] > 0 then
-    ##     TzFindCyclicJoins( T );
-    ##     if tietze[TZ_MODIFIED] then  TzSearch( T );  fi;
-    ##     if printstatus then  TzPrintStatus( T, true );  fi;
-    ## fi;
+    if tietze[TZ_TOTAL] > 0 then
+        TzFindCyclicJoins( T );
+        if tietze[TZ_MODIFIED] then  TzSearch( T );  fi;
+        if printstatus then  TzPrintStatus( T, true );  fi;
+    fi;

 end;

END OF  bugfix04.dif ________________________________________________________



From gaehler@orphee.polytechnique.fr Thu Mar 21 19:40:48 1996
Date:           Thu, 21 Mar 96 19:40:48 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        Graphic Conjugacy Class Lattice

Dear GAP-Forum,

I have uploaded my extensions of XGAP routine GraphicLattice
to ftp://ftp.math.rwth-aachen.de/pub/incoming/glatcc-1.0.tar.gz.
GraphicLattice now accepts an additional argument "Conjugacy Classes".
This argument instructs GraphicLattice to display a graphic
"subgroup conjugacy class lattice". Please note that the current
version is in file

   glatcc-1.0.tar.gz.

The files glat.doc, glatcc.tar.gz and glatcc.zoo belong to an earlier
version. That earlier version works, but is less complete.

Below I have attached a short documentation.

Enjoy!

With kind regards,

Franz G"ahler




Graphic Lattice for Conjugacy Classes of Subgroups - Documentation

This package is an extension to XGAP Version 1.3. It provides a
new version of GraphicLattice, which accepts a further, optional
argument "conjugacy classes" (or "Conjugacy Classes"). This argument
can also be abbreviated.

GraphicLattice( <group>, "conjugacy classes" ) returns a graph whose
vertices represent conjugacy classes of subgroups of <group>. Two
Vertices are connected if the representatives of one of the conjugacy
classes contain maximal subgroups from the other conjugacy class.

Compared to GraphicLattice( <group> ), the resulting graph is often
greatly simplified, as subgroups in the same conjugacy class are merged
into a single vertex. Of course, there is also some loss of information.
However, one can still inquire about all properties which are class
functions, so that a lot of useful information is still available.

If the mouse points to a vertex, the right mouse button menu allows to
inquire about properties of the representative of the conjugacy class
of a vertex. The results are all class functions, and thus are valid
throughout the whole class. In addition to the menu entries from
GraphicLattice( <group> ), an entry "Class size" has been added.

The Subgroups menu contains essentially the entries of the Subgroups
menu of GraphicLattice( <group> ). These entries still have the same
meaning, except that the conjugacy classes of the corresponding
subgroups are returned, instead of the subgroups themselves.
The menu entries "Closure" and "Closures" return the closures of
the whole subgroup conjugacy class, which is equal to the normal
closure of the selected representatives. Similarly, "Intersection"
and "Intersections" return the intersections of entire classes,
which is equal to the core (in the top level group) of the selected
representatives. "CommutatorSubgroups" has been omitted, as there
does not seem to be an obvious definition for this. Finally, a new
entry "Number of Copies" has been added to the Subgroups menu.
For each pair in the set of selected vertices, a message is issued,
telling how many maximal subgroups from one class are contained
in a representative of the other class, and how many minimal supergroups
a representative of one class has in the other class. If these numbers
are zero, no message is issued.

The CleanUp menu has been updated as well. "Select Representatives"
has been removed (this is not very useful, if every vertex is a
representative), and "Rotate Conjugates" (which isn't useful either
here) has been replaced by "Swap Vertices". This latter option allows
to swap two vertices, provided they are in the same horizontal strip.

All other menus work as for GraphicLattice( <group> ).

A vertex is represented internally by the representative of its conjugacy
class, and not by the conjugacy class itself. The benefit of this is
twofold: we can use most of the entries of the right mouse button menu
without modification, and Selected( <sheet> ) returns a list of subgroups,
which can be fed directly into InteractiveLattice. This allows to analyze
a subgraph in more detail, including the conjugates.


---
Franz G"ahler <gaehler@orphee.polytechnique.fr>
Centre de Physique Theorique, Ecole Polytechnique, F-91128 Palaiseau, France



From gaehler@orphee.polytechnique.fr Fri Mar 22 12:15:52 1996
Date:           Fri, 22 Mar 96 12:15:52 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        conjugands for subgroup Conjugacy Class

Dear GAP-Forum,

the GAP manual states that a Subgroup Conjugacy Class Record may
contain an optional field "conjugands". I have never ever been able
to make this field being bound, however. When computing the maximal
subgroups or minimal supergroups of a subgroup lattice, these
conjugands have to be computed, but apparently that information is
discarded afterwards. Which means that I have to recompute the
conjugands. After all, a minimal subgroup given in the form [n,m]
is of little value, if one does not know which conjugate of the
representative of class n carries number m! To find out you have
to recompute the conjugands...

Best regards,

Franz G"ahler



From gaehler@orphee.polytechnique.fr Fri Mar 22 12:21:05 1996
Date:           Fri, 22 Mar 96 12:21:05 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        GAP input buffer

Dear GAP-Forum,

is it possible to increase the input buffer of GAP beyond the 8000
characters? When debugging I like to paste in code from an editor
window. When I do this with little more than a dozen lines, GAP
beeps angrily. And so I often have to paste in routines in three
or four pieces. As the file often contains other code fragments,
perhaps a second version of the same routine, I don't want to
read in the whole file. I think I'd like an input buffer at least
5 times as big as it is now...

Best regards,

Franz G"ahler



From egner@ira.uka.de Sat Mar 23 15:09:10 1996
Date:           Sat, 23 Mar 96 15:09:10 +0100
From:           "Sebastian Egner" <egner@ira.uka.de>
Subject:        [no subject]

Subject: On the programming language `GAP'

Dear GAP-forum,

being an enthusiastic GAP user and programmer, I have
collected two suggestions on improving the GAP
language itself. Although I appreciate the idea of
`lean' languages, as for example GAP is, it seems
to me that GAP might benefit from these additions.
Especially ZF-comprehensions turned out to be so useful in
other languages I used before (Gofer, Haskell) that
I would be very glad to have it in GAP, too. In case these
ideas fit the general design considerations and
development strategy of the GAP-project I would
like to do actual implementation work on it.
Best regards,
  Sebastian Egner.


1. ZF-comprehensions for lists and sets.
----------------------------------------

A Zermelo-Fraenkel-comprehension (ZF-c.) is a compact notation to
denote a collection (list or set) of objects. It resembles the
standard mathematical notation for comprehensions. An examples is

  [ x^2 | for x in [100, 99 .. 1], IsPrime(x) ],

the list of squares of the primes not exceeding 100 in decending order.
Which could be written in GAP for example as

  List(Filtered([100, 99 .. 1], IsPrime), x -> x^2)

or explicitly (not working as printed; name the function) as

  ( function ()
      local result, x;

      result := [];
      for x in [100, 99 .. 1] do
        if IsPrime(x) then
          Add(result, x^2);
        fi;
      od;
      return result;
    end
  )()

Another example containing two generators ('for') yielding a set is

  { [n, r] | for n in [1..10], for r in PrimeResidues(n) },

the set of all pairs [n, r] being relative prime where 1 <= n <= 10.
This might be written in GAP as

  Union(List([1..10], n -> List(PrimeResidues(n), r -> [n, r]))).

or explicitly (not working, too) as

  ( function ()
      local result, n, r;

      result := Set([]);
      for n in [1..10] do
        for r in PrimeResidues(n) do
          AddSet(result, [n, r]);
        od;
      od;
      return result;
    end
  )()

The general ingrediences of a ZF-comprehension are
  * iterators to loop formal variables (`x', `n', `r') over
    structured homogeneous collections of objects (`[100, 99 .. 1]',
    `[1..10]', `PrimeResidues(n)'),
  * predicates to filter objects (`IsPrime(x)'), and
  * collectors to form the resulting homogeneous collection
    (`[ .. ]' and `{ .. }').

ZF-comprehensions do not add expressive power to the
GAP-language since they can always be replaced by expressions
in List(), Filtered(), Concatenation(), and Union().
However, they are very intuitive to read and write,
especially on the interactive input line. The implementation
has to be done in the underlying C-kernel since ZF-comprehensions
introduce a syntactic structures and set up a binding context
for the formal variables being used within the comprehension.
The syntactic expressions do not interfere with any other
existing structure, so old GAP-programs remain correct.


2. User-supplied iterators to run over structured objects
---------------------------------------------------------

The `for'-statement of GAP v3.x does only run over lists.
This implies that every time you iterate over the elements
of a structured object (like a group) the list of its
elements is formed before the iteration starts at all.
There is a particularly elegant way to extend the semantics
of the `for'-statement to run over structured objects:

The structured object obj has two additional fields in
its operations record to hold functions to do the iteration.
Namely an iterator record is produced by iter := newIterator(obj)
before the iteration begins. This record holds at least
the field iter.isEmpty containing a boolean value to indicate
if there is still an element to enumerate. While this flag
is false stepIterator(iter) modifies the iterator record
and sets iter.element to the current element.
The `for'-statement is augmented to recognize the case of
obj being no list but a record with an operations
field in which the two functions are available. In other words

  obj := rec(
    ..special data of the object..
    operations := rec(
      newIterator  := function (obj)  .. return iter; end, # custom-made
      stepIterator := function (iter) .. return; end,      # dito.
      ..more operations for the object..
    )
  );

so the iteration

  for x in obj do
    ..statements..
  od;

is unrolled to mean something like

  local iter;

  iter := obj.operations.newIterator(obj);
  while not iter.isEmpty do
    obj.operations.stepIterator(iter);
    x := iter.element;
    ..statements..
  od;

This feature can be implemented in the GAP-language itself
but it will be most useful if the C-kernel is modified to
augment the `for'-statement --- especially in conjunction
with ZF-comprehensions. Namely `for' needs to set up a local
variable to hold the iterator. (Which must *not* be stored
in obj.) Note that the modification of the GAP-language is
limited to the `for'-statement, does not interfere with
the existing semantics of `for', and the feature does not
rely on peculiarities of any particular GAP-domain.



From martin.schoenert@math.rwth-aachen.de Sat Mar 23 21:11:00 1996
Date:           Sat, 23 Mar 96 21:11:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: GAP input buffer

Franz Gaehler wrote in his message of 1996/03/22

    is it possible to increase the input buffer of GAP beyond the 8000
    characters? When debugging I like to paste in code from an editor
    window. When I do this with little more than a dozen lines, GAP
    beeps angrily.

Simply edit 'src/system.c' and replace 'char syHistory [8192];' with
'char syHistory [65536];'.  And recompile of course.

But very likely your problem is not due to GAP.  The 8000 limits how much
GAP remembers of what you type and how long a *single* line can get.
Besides GAP doesn't beep when you enter more, it simply discards the
oldest characters.  Also note that 8000 characters translates to 100
lines of 80 characters each, much more than the dozen lines you talk
about.

More likely the problem is with the X window system.  On many
implementations of X cutting and pastings more than a few hundred
characters causes lots of problems.  Unfortunately I don't think
there is a fix for it.

Martin.

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



From u640486@csi.uottawa.ca Sun Mar 24 11:46:54 1996
Date:           Sun, 24 Mar 96 11:46:54 -0500 (EST)
From:           "Istvan T. Hernadvolgyi" <u640486@csi.uottawa.ca>
Subject:        Shorter Words With AbStab

Hi,

 Recently I was playing around with the ordering of the points in the
stabilizer. I "invented" a heuristic that seems to dramatically improve the
word-length for the Rubik's Cube. I tried it on different permutation
groups as well. In general it does not improve for randomly generated
groups, but it does not seem to increase the word length either. For
groups "similar" to the Cube the improvement holds.

I ran a test of sample size 500 on the Cube. Using FactorPermGroupElement
without shrinking I obtained 86.528 % shorter paths. The lowest
improvement was 43% while the highest 97%. Using Shrink the word length
usually gets below 100.

The paths were all tested algebraically and "visually". I made up a simple
description language that generates displays for permutation groups.

 The problem I am having is, that I cannot explain myself why it works so
well. I include here the few functions that make up the heuristic, and how
to use it. Anyone interested, please feel free to use it. I would truely
appreciate any comments and maybe even an explanation. (I am not a
mathematician, just a "poor" undergrad in Computer Science).

How to use it??

Very easy. Set a field "heuristic" to true for the group you are passing
to FactorPermGroupElement or Shrink.

like:
   cube.heuristic:=true;

   FactorPermGroupElement(cube,Random(cube));


Changes to AbStab.

Almost nothing:

Add the four lines to MakeStab or MakeShortStab here:

    Append(base, Difference( PermGroupOps.MovedPoints( G ), base ) );

    ##########################################################
    # Add The next 4 lines here in MakeSatb or MakeShortSatb #
    ##########################################################
    if IsBound(G.heuristic) and G.heuristic
    then
      base := Reversed(SortByGeneratorsOnOrbits(G,base));
    fi;

    l := 1;
    while l <= Length( base ) and
                ForAll( gens, gen -> base[l] ^ gen = base[l] )  do
        l := l + 1;
    od;


And add the next four lines in MakeAbStabChain:

        G.stabilizerSubgroup := H;

        #############################################
        # Add these next four lines here            #
        #############################################
        if IsBound(G.heuristic) and G.heuristic
        then
          H.heuristic := true;
        fi;

        MakeAbStabChain( H, l );


The functions. I call the file  "strip.g". Make sure AbStab.g reads them.

Here are all:


sortfunc := function(L1,L2)
  return Length(L1) < Length(L2);
end; # sortfunc

LargestPoint := function(G)
  local Result,L;

  Result := 0;
  L := PermGroupOps.MovedPoints(G);

  if Length(L) > 0
  then
    Result := Maximum(L);
  fi;

  return Result;
end; # LargestPoint

TrivialBase := function(G)
  local orbitGroup,orbit,coupledElements,head;

  if not IsBound(G.trivialBase)
  then
     G.trivialBase := [];
     if not IsBound(G.orbits)
     then
        G.orbits := Orbits(G,[1..LargestPoint(G)]);
        Sort(G.orbits,sortfunc);
     fi;
     for orbit in [1 .. Length(G.orbits)]
     do
       orbitGroup := Operation(G,G.orbits[orbit]);
       coupledElements := Blocks(orbitGroup,[1..Length(G.orbits[orbit])]);
       for head in [1..Length(coupledElements)]
       do
         Add(G.trivialBase,G.orbits[orbit][coupledElements[head][1]]);
       od;
     od;
  fi;
end; # TrivialBase


StripBase := function(G,L)
  local Result,element;

  Result := [];
  TrivialBase(G);
  for element in [1 .. Length(L)]
  do
    if L[element] in G.trivialBase
    then
      Add(Result,L[element]);
    fi;
  od;

  return Result;
end; # StripBase

SortByGeneratorsOnOrbits := function(G,L)
  local i,j,genpoints,list,list2,Result1,Result;

  genpoints := [];
  Result := [];
  Result1 := [];

  for i in [1..Length(G.generators)]
  do
    list := Cycles(G.generators[i],
                   [
                    SmallestMovedPointPerm(G.generators[i])
                    ..
                    LargestMovedPointPerm(G.generators[i])
                   ]
                  );
    list2 := [];
    for j in [1..Length(list)]
    do
      if Length(list[j]) > 1
      then
        Add(list2,list[j]);
      fi;
    od;
    list2 := Flat(list2);
    for j in [1..Length(list2)]
    do
      if not list2[j] in Result1
      then
        Add(Result1,list2[j]);
      fi;
    od;
  od;

  Result1 := StripBase(G,Result1);

  for i in [1..Length(Result1)]
  do
    if Result1[i] in L and not Result1[i] in Result
    then
      Add(Result,Result1[i]);
    fi;
  od;

  return Result;
end;



Thanks,

 --

 - Istvan

 Istvan T. Hernadvolgyi | http://www.csi.uottawa.ca/~u640486
 u640486@csi.uottawa.ca |   (Canada) -( 613 ) - 749 - 5191



From adorio@math.upd.edu.ph Sat Mar 23 20:22:52 1996
Date:           Sat, 23 Mar 96 20:22:52 +0800
From:           "Ernesto P. Adorio" <adorio@math.upd.edu.ph>
Subject:        Dimino's algorithm

I used the ff. algorithm to generate sequentially n elements of a group
before I discovered GAP. It was slow for interactive use (generating
elements of a plane crystallographic group),  but it may interest other
users of GAP. It is written in pseudo-code here.

C = {e}     output group initially containing the identity element
A = {e}     active block of elements
N = {}      set of newly generated elements
G =  {g1, g2, ..., gk}  set of k generators excluding the identity element
n = number of group elements desired

count = 1
while A <> {}
    for each a in A
       for each g in G
           if a*g not in C or a*g not in A or a*g not in N
                N = N U { a*g}      // U is set union
                count = count + 1
                if count = n
                   return C
                endif
           endif
       next
    next
    C = C U A
    A = N
    N = {}       reset N
wend
return C

Is this just a well-known variant of the Dimino's algorithm?



From martin.schoenert@math.rwth-aachen.de Mon Mar 25 21:53:00 1996
Date:           Mon, 25 Mar 96 21:53:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: GAP input buffer

I hate to follow up on my own message of 1996/03/23, but I finally
remembered where I found the note that cutting and pasting are
problematic under X.  From the 'xterm' manual page

    BUGS
        Large pastes do not work on some systems.  This is  not  a
        bug in xterm; it is a bug in the pseudo terminal driver of
        those systems.  xterm feeds large pastes to the  pty  only
        as  fast as the pty will accept data, but some pty drivers
        do not return enough information to know if the write  has
        succeeded.

You can test whether this is what happens to you by simply pasting into
'cat' instead of GAP.

Unfortunately that still doesn't help you of course.  But maybe you can
find a fixed version of 'xterm' for your system.

Martin.

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



From martin.schoenert@math.rwth-aachen.de Mon Mar 25 21:58:00 1996
Date:           Mon, 25 Mar 96 21:58:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: conjugands for subgroup Cubjugacy Class

Franz Gaehler wrote in his email message of 1996/03/22

    the GAP manual states that a Subgroup Conjugacy Class Record may
    contain an optional field "conjugands". I have never ever been able
    to make this field being bound, however. When computing the maximal
    subgroups or minimal supergroups of a subgroup lattice, these
    conjugands have to be computed, but apparently that information is
    discarded afterwards. Which means that I have to recompute the
    conjugands. After all, a minimal subgroup given in the form [n,m]
    is of little value, if one does not know which conjugate of the
    representative of class n carries number m! To find out you have
    to recompute the conjugands...

We don't store the conjugands in the lattice or the subgroup conjugacy
class record, because it would require much too much storage (it would
make some of the lattice computations we did impossible with any
reasonable amount of memory).

Unfortunately it is impossible to recompute the conjugands afterwards.
This is because during the lattice computation the conjugands are
computed as the right transversal of the normalizer of the
representative.  But 'RightTransversal' is not guaranteed to return the
same transversal if you call it after the lattice computation.

However, it is simple to modify 'MaximalSubgroups' and
'MinimalSupergroups' so that they not only give a subgroup in the form
'[<n>,<m>]' (which means <n>-th conjugacy class, <m>-th subgroup of that
class), but '[<n>,<m>,<c>]' where <c> is a conjugating element.
If you are interested, write me and I will send you the code.

Martin.

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



From martin.schoenert@math.rwth-aachen.de Tue Mar 26 12:26:00 1996
Date:           Tue, 26 Mar 96 12:26:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: On the programming language `GAP'

Sebastian Egner wrote in his mail message of 1996/03/23

    being an enthusiastic GAP user and programmer, I have collected two
    suggestions on improving the GAP language itself.  Although I appreciate
    the idea of `lean' languages, as for example GAP is, it seems to me that
    GAP might benefit from these additions.  Especially ZF-comprehensions
    turned out to be so useful in other languages I used before (Gofer,
    Haskell) that I would be very glad to have it in GAP, too.  In case these
    ideas fit the general design considerations and development strategy of
    the GAP-project I would like to do actual implementation work on it.

Thank you very much for your suggestions and your offer to help us
implement them.

Iterators will be supported in the next version of GAP.  The names
and semantics will be very similar to the ones you suggest.

I also like list comprehensions very much.  They are especially useful
for interactive use (but I don't use them often in my programs).

However comprehensions with the syntax you describe require major changes
to the parser.  In particular they require unbounded lookahead (whether a
variable in the expression refers to an outer variable or a loop variable
cannot be decided before the entire comprehension has been parsed).

I think that a small change to 'List', 'Set' are almost as good.  Allow
me to describe them (using 'List' as example).

'List' would take 2 or more arguments.  Every argument but the last can be
1) a list or a domain (to introduces a new loop variable),
2) a function returning a list or a domain (to have the elements to loop
    over depend on the values of the outer loop variables),
3) a function returning 'true' or 'false' (to filter).
The last argument must be function, which is applied to the values of
the loop variables and whose results are collected.

Understanding this function is probably much easier by examples than from
a formal definition. So here is how your first example

    [ x^2 | for x in [100, 99 .. 1], IsPrime(x) ]             # comprehension

can be expressed using this extended 'List'

    List( [100, 99 .. 1], x -> IsPrime(x), x -> x^2 )         # GAP

or since 'x -> IsPrime(x)' is equivalent to 'IsPrime'

    List( [100, 99 .. 1], IsPrime, x -> x^2 )                 # GAP

(which is even shorted than the comprehension).

And your second example

    { [n, r] | for n in [1..10], for r in PrimeResidues(n) }  # comprehension

can be written as follows

    Set( [1..10], n->PrimeResidues(n), function(n,r) return [n,r] end ) # GAP

Of course it would be nice to have a short notation for functions of more
than one argument, so that the latter can be written as

    Set( [1..10], n -> PrimeResidues(n), (n,r) -> [n,r] )

Using the function 'ListArgs', which simply returns the list of its
arguments (i.e., 'ListArgs := function ( args ) return args; end;'),
we can express the last examples as follows

    Set( [1..10], PrimeResidues, ListArgs )                   # GAP

(which is pretty short, but not so easy to read).

One nice thing is that it is easy to generalize 'Sum' and 'Product'
likewise.  With comprehensions you would either have to create the entire
list and sum afterwards or come up with yet another syntactic extension.

Kindly, Martin.

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



From gaehler@orphee.polytechnique.fr Tue Mar 26 13:14:15 1996
Date:           Tue, 26 Mar 96 13:14:15 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        Re: GAP input buffer

Dear GAP-Forum:

Martin Schoenert wrote:

> I hate to follow up on my own message of 1996/03/23, but I finally
> remembered where I found the note that cutting and pasting are
> problematic under X.  From the 'xterm' manual page
>
>     BUGS
>         Large pastes do not work on some systems.  This is  not  a
>         bug in xterm; it is a bug in the pseudo terminal driver of
>         those systems.  xterm feeds large pastes to the  pty  only
>         as  fast as the pty will accept data, but some pty drivers
>         do not return enough information to know if the write  has
>         succeeded.
>
> You can test whether this is what happens to you by simply pasting into
> 'cat' instead of GAP.

If I type "cat << !" and then paste a large piece of text into that
window, I have no problem. I have found a workaround though: if I use
XGAP, which opens its own window, the problem goes away...

Best regards,

Franz G"ahler



From martin.schoenert@math.rwth-aachen.de Tue Mar 26 15:18:00 1996
Date:           Tue, 26 Mar 96 15:18:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Dimino's algorithm

Ernesto P. Adorio wrote in his mail message of 1996/03/23

    I used the ff. algorithm to generate sequentially n elements of a group
    before I discovered GAP.
    ...code omitted...
    Is this just a well-known variant of the Dimino's algorithm?

No this is just a simple implementation of the orbit algorithm.
At least it is if you replace the line

           if a*g not in C or a*g not in A or a*g not in N
                           ^^              ^^
with

           if a*g not in C and a*g not in A and a*g not in N
                           ^^^              ^^^
Otherwise I think you algorithm may not terminate.

Your algorithm can be improved slightly by directly moving new elements
into C, so one membership test (instead of the three above) suffices.

    C := [ e ];    # set of all found elements
    N := [ e ];    # new elements
    while N <> []  do
        A := N;
        N := [];
        for a in A do
            for g in gens do
                if not a*g in C then
                    AddSet( C, a*g );
                    Add( N, a*g );
                fi;
            od;
        od;
    od;

The Dimino algorithm works somewhat different.
First it computes the list of elements of < g_1 >
(the subgroup generated by the first generator).
Then it computes the list of elements of < g_1, g_2 >.
If it finds a new element <g> it adds the whole coset < g_1 > * <g>.
Then it computes the list of elements of < g_1, g_2, g_3 >.
If it finds a new element <g> it adds the whole coset < g_1, g_2 > * <g>.
And so on until it has computed the list of elements of < g_1, ..., g_n >.

    C := [ e ];
    for i in [1..n]  do
        D := C;
        N := [ e ];
        while reps <> []  do
            A := N;
            N := [];
            for a in A do
                for g in gens{[1..i]} do
                    if not a*g in C  then
                        UniteSet( C, D * (a*g) );
                        Add( N, a*g );
                    fi;
                od;
            od;
        od;
    od;

Since it only tests membership for the representatives of the cosets,
and adds the other elements without membership tests,
it uses fewer membership tests and is therefore faster.
The smaller the indices [ < g_1, ..., g_{i+1} > : < g_1, ..., g_i > ]
are, the more it wins.

Martin.

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



From gaehler@orphee.polytechnique.fr Tue Mar 26 16:02:28 1996
Date:           Tue, 26 Mar 96 16:02:28 +0100
From:           "Franz Gaehler" <gaehler@orphee.polytechnique.fr>
Subject:        Re: conjugands for subgroup Cubjugacy Class

Dear GAP-Forum:

Martin Schoenert replied to my email message of 1996/03/22:

> Unfortunately it is impossible to recompute the conjugands afterwards.
> This is because during the lattice computation the conjugands are
> computed as the right transversal of the normalizer of the
> representative.  But 'RightTransversal' is not guaranteed to return the
> same transversal if you call it after the lattice computation.

This surprises me a bit. I thought I could reliably recompute the
SAME right transversal, and so far didn't have any problems with that
assumption. Under what conditions may it happen that subsequent
invocations of RightTransversal yield different results? If different
results can indeed occur (more precisely: different orderings in the
list of cosets), I do not see how GraphicLattice (from XGAP) could
reliably produce the correct result. In the function
GraphicLatticeOps.MakeMaximalSubgroups the right transversals of
subgroup conjugacy class representatives are computed two or more times,
and it seems that it is assumed that always the same result is obtained.
But perhaps I have overlooked some invariance in the topology of the
graph produced by GraphicLattice.

> However, it is simple to modify 'MaximalSubgroups' and
> 'MinimalSupergroups' so that they not only give a subgroup in the form
> '[<n>,<m>]' (which means <n>-th conjugacy class, <m>-th subgroup of that
> class), but '[<n>,<m>,<c>]' where <c> is a conjugating element.
> If you are interested, write me and I will send you the code.

I think it would be a good solution if MaximalSubgroups and
MinimalSupergroups would accept a flag which makes them return
the results in the way you suggest, of even make this the default
behaviour (provided that memory requirements permit, and that nothing
breaks if triples are returned instead of pairs). This would allow
to avoid all these problems.

In any case, I would appreciate receiving your code.

Best regards,

Franz G"ahler



From u640486@csi.uottawa.ca Thu Mar 28 10:16:38 1996
Date:           Thu, 28 Mar 96 10:16:38 -0500 (EST)
From:           "Istvan T. Hernadvolgyi" <u640486@csi.uottawa.ca>
Subject:        Rubik's Cube

hi,

 I am just wondering, if someone could give me a meaningful estimate on
the diameter of the Cayley Graph for the 3x3x3 Rubik's Cube. I know it is
11 for the 2x2x2.

Guesses are welcome.


thanks in advance,

 --

 - Istvan

 Istvan T. Hernadvolgyi | http://www.csi.uottawa.ca/~u640486
 u640486@csi.uottawa.ca |   (Canada) -( 613 ) - 749 - 5191



From nordbeem@caa.mrs.umn.edu Thu Mar 28 09:57:04 1996
Date:           Thu, 28 Mar 96 09:57:04 -0500
From:           "Eric Nordberg " <nordbeem@caa.mrs.umn.edu>
Subject:        access to your server

I was interested in how to access the files on the gap server remotely.
I apoligize for the huge amounts of computer ignorance on my part.
regards,
Eric Nordberg



From u640486@csi.uottawa.ca Thu Mar 28 15:46:29 1996
Date:           Thu, 28 Mar 96 15:46:29 -0500 (EST)
From:           "Istvan T. Hernadvolgyi" <u640486@csi.uottawa.ca>
Subject:        Rubik's Cube

Hi,

 Thanks for Paul R. Brown's correction. As I formed the question is
 obviously silly.

 I am interested in the diameter of the Cayley Graph for the Cube with
 the 6 generators that move each face. More specifically, in both cases:
 with and without the inverses "allowed" to be in the path.

 I would also be interested in the diameter when the generators are the
 above mentioned 6, and their pair-wise conjugates.


 Thank you very much for the correction, and again, guesses are welcome.

thanks,

 --

 - Istvan

 Istvan T. Hernadvolgyi | http://www.csi.uottawa.ca/~u640486
 u640486@csi.uottawa.ca |   (Canada) -( 613 ) - 749 - 5191



From frank.celler@math.rwth-aachen.de Fri Mar 29 13:19:00 1996
Date:           Fri, 29 Mar 96 13:19:00 +0100 (MET)
From:           "Frank Celler" <Frank.Celler@Math.RWTH-Aachen.DE>
Subject:        RE: access to your server

Dear Eric Nordberg,

you can  access our server using  the "ftp" program which is available
on all  UNIX machines.  There   are also ports  for DOS and  MAC.   As
alternative you can use a WWW browser to access the files.

If you are going to use  a WWW browser, say  lynx or netscape, use the
location

    http://www.math.rwth-aachen.de/ftp/

to start with and follow the links pub, gap, README.

If you are going to use a FTP program, start it using (under UNIX)

    ftp ftp.math.rwth-aachen.de

it will then ask for a login name (use "ftp") and a password (use your
email address).   You can then  use "dir" to get  a directory, "cd" to
change into a  subdirectory, "get" to  get a text  file, and "bin" and
"get" to get a binary file.  For instance, to ftp the readme file:

    unix> ftp ftp.math.rwth-aachen.de
    Connected to samson.math.rwth-aachen.de.
    220 samson FTP server ready.
    Name (ftp.math.rwth-aachen.de:fceller): ftp
    331 Guest login ok, send your complete e-mail address as password.
    Password: Name@My.Domain.Edu
    ftp> bin
    200 Type set to I.
    ftp> cd pub/gap
    250 CWD command successful.
    ftp> dir
    200 PORT command successful.
    150 Opening ASCII mode data connection for /bin/ls.
    total 9637
    -r--r--r--  1 ftp      system       1624 Mar 13 12:36 CONTENTS
    -r--r--r--  1 ftp      system      43967 Dec 22 12:22 README
    ...
    dr-xr-xr-x  2 ftp      system        512 Mar 13 12:39 util
    226 Transfer complete.
    ftp> get README
    local: README remote: README
    200 PORT command successful.
    150 Opening BINARY mode data connection for README (43967 bytes).
    226 Transfer complete.
    43967 bytes received in 0.27 seconds (1.6e+02 Kbytes/s)
    ftp> quit
    221 Goodbye.
    unix> more README

The README file  describes which files are  needed to install GAP.  If
you have any further problems, please email

    gap-trouble@Math.RWTH-Aachen.DE

cheers
    Frank



From martin.schoenert@math.rwth-aachen.de Fri Mar 29 14:52:00 1996
Date:           Fri, 29 Mar 96 14:52:00 +0100 (MET)
From:           "Martin Schoenert" <Martin.Schoenert@Math.RWTH-Aachen.DE>
Subject:        Re: Rubik's Cube

Istvan T. Hernadvolgyi wrote in his message of 1993/03/28

    I am just wondering, if someone could give me a meaningful estimate on
    the diameter of the Cayley Graph for the 3x3x3 Rubik's Cube. I know it is
    11 for the 2x2x2.

Paul R. Brown replied (and accidently also mailed this reply to the
GAP-Forum, where it was rejected), pointing out that this question only
makes sense when one specifies a set of generators.

Istvan answered in his next message

    I am interested in the diameter of the Cayley Graph for the Cube with
    the 6 generators that move each face. More specifically, in both cases:
    with and without the inverses "allowed" to be in the path.

I don't think anybody looks at Cayley graphs without including inverses
of the generators.  If you do this, very unpleasant things happen.  For
example, you no longer obtain a measure.  Different points in the graph
may have different distances from their antipode(s).  And so on.

Lets take the Cayley graph with respect to the 6 quarter turn generators
and their inverses.  This is usually called God's algorithm.  I.e., how
many quarter turns would God have to make to bring a state back to the
solved state in the worst case?

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

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

Thus we know that the diameter must lie between 24 and 42.
The agreement seems to be that the true answer will be very close to 24.
So I don't think anybody is working on raising the lower bound.  On the
other hand, I don't think anybody has an idea how to lower the upper
bound much.

Istvan continued

    I would also be interested in the diameter when the generators are the
    above mentioned 6, and their pair-wise conjugates.

I don't have the slightest idea.

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

http://WWW.Math.RWTH-Aachen.DE/Private/HomePages/Martin_Schoenert/Cube-Lovers/

Martin.

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



