This file contains the mails sent to the GAP forum in July-September 1992.

Name               Email address                           Mails    Lines
Martin Schoenert   martin@bert.math.rwth-aachen.de            18     1497
S. Linton          sl25@cus.cam.ac.uk                          7      299
Werner Nickel      werner@pell.anu.edu.au                      5       98
Frank Celler       fceller@bert.math.rwth-aachen.de            4      173
Joachim Neubueser  neubuese@samson.math.rwth-aachen.de         4       76
Geoffrey Mess      geoff@math.ucla.edu                         3       63
N. S. Mendelsohn   mendel@ccu.umanitoba.ca                     3       26
Charley Wright     wright@bright.uoregon.edu                   2       97
A.E. Brouwer       aeb@win.tue.nl                              2       66
Boris Hemkemeier   boris@mathematik.uni-bielefeld.de           2       33
Mustafa Akgul      akgul@trbilun.bitnet                        2       23
Geoff Smith        gcs@maths.bath.ac.uk                        2       15
Toni Greil         greil@guug.de                               1       93
Ralf Dentzer       dentzer@kalliope.iwr.uni-heidelberg.de      1       35
John R. Neil       neil@dehn.mth.pdx.edu                       1       30
David Sibley       sibley@math.psu.edu                         1       29
Jackie Ford        ffor@gauss.math.rochester.edu               1       13
Lewis Stiller      lstiller@goshawk.lanl.gov                   1        9
Simon Paul Ronald  maspr@lux.levels.unisa.edu.au               1        9
Eamonn O'Brien     obrien@pell.anu.edu.au                      1        9
Nick Phillips      nick@siucbal.c-cs.siu.edu                   1        5

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 sl25@cus.cam.ac.uk Mon Aug 10 14:10:55 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Mon, 10 Aug 92 14:10:55 +0200
Subject:    Various suggestions

The forum has been very quiet lately, so I thought I'd raise
a few suggestions that have occurred to me recently.

1) It would be nice to be able to access the operating system 
environment from GAP. A function Getenv(string) perhaps and/or
an array Environment of pairs of strings.

2) ITIt would be nice to have a structure that behaved like a 
hash-table or a PERL associative array. This would enable
general Orbit algorithms to go MUCH faster. More generally
Aho, Hopcraft and Ulmann (Design and Analysis...) has a nice
general description of 'dictionaries' in terms of which
operations can be carried out quickly. A set of constructs 
implementing these would be extremely useful.

3) Especially on PCs (I don't know about STs) repeated use of
AppendTo is very slow as the file has to be closed and the
directory updated between each call. It would be nice to
have fopen, fread/write and fclose -like calls using some
sort of file handle.

4) It would be nice to be able to control the level of
printing when entering a break loop. When the progran is in a
recursive procedure or something I often loose the piece of information
I want off the end of the traceback.

5) Also for debugging purposes, it would be nice to be able to 
look past a local variable at a 'hidden' variable of the same
name in an outer scope. Either some way of saying 'The global x'
and the 'the x belonging to procedure foobar' (though what happens
if foobar is recursed 8 levels deep?) or of saying 'The x in the
scope outside this one'.

6) Possibly the read-eval-print loop should suppress or abbreviate
the printing of very long results. 

Anyway, what do other people think about these ideas?

		Steve



From sibley@math.psu.edu Mon Aug 10 17:53:42 1992
From:       sibley@math.psu.edu "David Sibley"
Date:       Mon, 10 Aug 92 17:53:42 +0200
Subject:    Permutation groups from Ag groups

How do I make a permutation group from an Ag group?  Specifically,
I would like to get the action on the cosets of a subgroup.  The
following is a summary of what I tried, but it doesn't work.

(BTW, is this forum broken?  I have not received any messages in
it for over a month.)

David Sibley
sibley@math.psu.edu
-------------------------------------------------------------
gap> a:=TwoGroup(256,3678);;
gap> b:=Subgroup(a,[a.1^2,a.2^2,a.3^2]);;
gap> g:=Operation(a,Cosets(a,b),OnRightCosets);;
Error, for: <list> must evaluate to a list at
for <var>  in set ... in
opr( D[i], gen ) called from
arg[1].operations.Operation( arg[1], arg[2], arg[3] ) called from
Operation( a, Cosets( a, b ), OnRightCosets ) called from
main loop
brk> quit;
gap> g:=OperationCosetsFpGroup(a,b);;
Error, Record: element 'relators' must have an assigned value at
if gen ^ 2 in G.relators or gen ^ (-1 * 2) in G.relators ... in
CosetTableFpGroup( G, H ) called from
OperationCosetsFpGroup( a, b ) called from
main loop
brk> quit;
gap>



From werner@pell.anu.edu.au Mon Aug 10 21:24:04 1992
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Mon, 10 Aug 92 21:24:04 +0200
Subject:    Re:  Gap-Forum

Okay, this is just a test mail to the GAP forum. I haven't heard anything
from the forum for quite a while and just want to see if it is still
working.

Werner Nickel



From fceller@bert.math.rwth-aachen.de Tue Aug 11 08:55:08 1992
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 11 Aug 92 08:55:08 +0200
Subject:    Re: Re:  Gap-Forum

WN>Okay, this is just a test mail to the GAP forum. I haven't heard anything
WN>from the forum for quite a while and just want to see if it is still
WN>working.

This is due to a problem with our list-server, we hope to solve the
problem in the near future. Sorry for any inconvenience

    Frank



From fceller@bert.math.rwth-aachen.de Tue Aug 11 09:26:34 1992
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 11 Aug 92 09:26:34 +0200
Subject:    Re: Permutation groups from Ag groups

Dear David,

DS> following is a summary of what I tried, but it doesn't work.
DS>
DS> gap> a:=TwoGroup(256,3678);;
DS> gap> b:=Subgroup(a,[a.1^2,a.2^2,a.3^2]);;
DS> gap> g:=Operation(a,Cosets(a,b),OnRightCosets);;
DS> Error, for: <list> must evaluate to a list at
DS> for <var>  in set ... in
DS> opr( D[i], gen ) called from
DS> arg[1].operations.Operation( arg[1], arg[2], arg[3] ) called from
DS> Operation( a, Cosets( a, b ), OnRightCosets ) called from
DS> main loop

this is because the name 'OnRightCosets' is (unfortunately) misleading.
'OnRightCosets' expects a set $S$ and an element $g$ and returns $Sg$.
For cosets you should use 'OnRight'.

  gap> a := TwoGroup( 256, 3678 );
  Group( a1, a2, a3, a4, a5, a6, a7, a8 )
  gap> b := Subgroup( a, [a.1^2,a.2^2,a.3^2] );
  Subgroup( Group( a1, a2, a3, a4, a5, a6, a7, a8 ), [ a4*a5*a6, a4*a5, a4 ] )
  gap> g := Operation( a, Cosets(a,b), OnRight );
  Group( ( 1,17)( 2,18)( 3,19)( 4,20)( 5,21, 8,24)( 6,22, 7,23)( 9,25,11,27)
  (10,26,12,28)(13,29,14,30)(15,31,16,32), ( 1, 9)( 2,10)( 3,11)( 4,12)
  ( 5,13, 7,15)( 6,14, 8,16)(17,28,18,27)(19,26,20,25)(21,32,24,29)
  (22,31,23,30), ( 1, 5)( 2, 6)( 3, 7)( 4, 8)( 9,16,10,15)(11,14,12,13)
  (17,22,19,24)(18,21,20,23)(25,32,28,29)(26,31,27,30), ( 9,10)(11,12)(13,14)
  (15,16)(17,19)(18,20)(21,23)(22,24)(25,28)(26,27)(29,32)(30,31), ( 5, 7)
  ( 6, 8)( 9,10)(11,12)(13,16)(14,15)(17,20)(18,19)(21,22)(23,24)(25,27)
  (26,28), ( 5, 6)( 7, 8)( 9,11)(10,12)(13,16)(14,15)(17,18)(19,20)(25,28)
  (26,27)(29,31)(30,32), ( 1, 3)( 2, 4)( 5, 7)( 6, 8)( 9,11)(10,12)(13,15)
  (14,16)(17,19)(18,20)(21,23)(22,24)(25,27)(26,28)(29,31)(30,32), ( 1, 2)
  ( 3, 4)( 5, 6)( 7, 8)( 9,10)(11,12)(13,14)(15,16)(17,18)(19,20)(21,22)(23,24)
  (25,26)(27,28)(29,30)(31,32) )

DS> (BTW, is this forum broken?  I have not received any messages in

We do have some problems with our list server.

mfg
  Frank



From gcs@maths.bath.ac.uk Wed Aug 12 12:01:31 1992
From:       gcs@maths.bath.ac.uk "Geoff Smith"
Date:       Wed, 12 Aug 92 12:01:31 +0200
Subject:    SPAS

I would like to give credit to SPAS in a forthcoming paper. Can someone suggest
an appropriate reference?

Geoff



From neubuese@samson.math.rwth-aachen.de Wed Aug 12 12:48:01 1992
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed, 12 Aug 92 12:48:01 +0200
Subject:    SPAS

Geoff Smith  asks for a reference for SPAS.  I am afraid there isn't a
very useful  one. You  might  quote  the "User's Reference Manual" for
version  2.5  of SPAS  of  1989,  written largely  by  Volkmar Felsch,
although his  authorship is not mentioned on  the  title page; what is
given there is just the place of origin "Lehrstuhl D f\"ur Mathematik,
RWTH  Aachen"  since the manual was  started  with  some  descriptions
written by students. There is no other publication that you can quote.

However since a  very  substantial part  of SPAS  consists  of several
programs written  as standalone  programs e.g.   by  George Havas  and
others, as stated very explicitely in the introduction of the  manual,
for a particular computation it  may  be not only more appropriate but
also more informative to quote these programs  and the publications on
them that can be found from that introduction and the bibliography  of
the manual.

Joachim Neubueser



From gcs@maths.bath.ac.uk Wed Aug 12 13:17:42 1992
From:       gcs@maths.bath.ac.uk "Geoff Smith"
Date:       Wed, 12 Aug 92 13:17:42 +0200
Subject:    Re: SPAS

Thanks Joachim. Mike Newman has used SPAS to verify a result I obtained
another way. I shall put the reference manual as a provisional
reference, and possibly change it to something more specific
when I get Mike's full report.

as ever Geoff

(PS The result is that the Fibonacci Group F(4,7) is infinite --
 a Golod-Saverevic argument).



From wright@bright.uoregon.edu Fri Aug 14 02:12:55 1992
From:       wright@bright.uoregon.edu "Charley Wright"
Date:       Fri, 14 Aug 92 02:12:55 +0200
Subject:    Elements of order 4 in a subgroup of order 2


Greetings!  I've been spending quite a bit of time working with GAP this summer, and
hope to be able to have something to show for it before long.  At the moment, though, 
I've run into a bug of some sort.  Here's a log of what happened.

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


# This first chunk builds n-fold (...(C_p wr C_p) wr ... )wr C_p.

wreathPower := function (p, n)

local c, g, rc, cc, alpha;

c := CyclicGroup(AgWords, p);
g := c;
rc := RightCosets(c, TrivialSubgroup(c));
cc := Operation (c, rc, OnRight);
alpha := GroupHomomorphismByImages (c, cc, c.generators, cc.generators);

while n > 1 do
	g := WreathProduct (g, c, alpha);
	n := n-1;
od;

return g;

end;;

# Now we use it to build a group whose subgroups have strange properties.


gap> A := wreathPower(2,3);  # = (2wr2)wr2
Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 )

gap> B := AgSubgroup(A,[A.4*A.5*A.6],true);
Subgroup( Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 ), [ n1_3*n2_1*n2_2 ] )

gap> Size(B);
2

gap> c := A.4*A.5*A.6;
n1_3*n2_1*n2_2

gap> c^2;
n2_2*n2_3

gap> c in B;
true

gap> Elements(B);
[ IdAgWord, n1_3*n2_1*n2_2 ]

gap> c^2 in B;
false

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

Is this a known bug?  
(I have applied both patches, so I know it is not fixed by either of them.)

Charley
-- 

wright@math.uoregon.edu

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



From fceller@bert.math.rwth-aachen.de Fri Aug 14 09:35:11 1992
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Fri, 14 Aug 92 09:35:11 +0200
Subject:    Re: Elements of order 4 in a subgroup of order 2

Charley Wrigth writes:

CW> I've run into a bug of some sort.  Here's a log of what happened.
CW> 
CW> gap> A := wreathPower(2,3);  # = (2wr2)wr2
CW> Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 )
CW> gap> B := AgSubgroup(A,[A.4*A.5*A.6],true);
CW> Subgroup( Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 ), [ n1_3*n2_1*n2_2 ] )
CW> gap> Size(B);
CW> 2
CW> gap> c := A.4*A.5*A.6;
CW> n1_3*n2_1*n2_2
CW> gap> c^2;
CW> n2_2*n2_3
CW> gap> c in B;
CW> true
CW> gap> Elements(B);
CW> [ IdAgWord, n1_3*n2_1*n2_2 ]
CW> gap> c^2 in B;
CW> false

This is not really a bug, but a feature. Consider the following:

  gap> A := wreathPower(2,3);
  Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 )

  gap> c := A.4*A.5*A.6;
  n1_3*n2_1*n2_2

  gap> B := Subgroup( A, [c] );
  Subgroup( Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 ), [n1_3*n2_1*n2_2] )

  gap> c in B;
  true

  gap> Elements(B);
  [ IdAgWord, n2_2*n2_3, n1_3*n2_1*n2_3, n1_3*n2_1*n2_2 ]

  gap> c^2 in B;
  true

And now it works.  So  the  "bug" must  be  in line  "B := AgSubgroup(...);".
Indeed the  function  'AgSubgroup' assumes that the second argument is either
an induced generating  system or  a canonical one.  It  does *not* check this
assumption, because  the function is intented  to be used in functions  which
already know  that they have computed an canonical generating system and want
to convert it to  a subgroup  structure.  Checking the  arguments  would be a
waste of time in this case. 'Subgroup' is  intented to  be used by  users and
function  which compute just  generating sets for a subgroup without assuming
that the  generating set is a canonical one.  So let us compute the canonical
generating system.

  gap> Cgs(B);
  [ n1_3*n2_1*n2_3, n2_2*n2_3 ]

Now we can try again.

  gap> A := wreathPower(2,3);
  Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 )

  gap> c := A.4*A.5*A.6;
  n1_3*n2_1*n2_2

  gap> c^2;
  n2_2*n2_3

  gap> B := AgSubgroup( A, [c,c^2], true );
  Subgroup( Group( h, n1_1, n1_2, n1_3, n2_1, n2_2, n2_3 ),
  [ n1_3*n2_1*n2_2, n2_2*n2_3 ] )

  gap> c in B;
  true

  gap> Elements(B);
  [ IdAgWord, n2_2*n2_3, n1_3*n2_1*n2_3, n1_3*n2_1*n2_2 ]

  gap> c^2 in B;
  true

mfg (=with best regards)
  Frank



From wright@bright.uoregon.edu Fri Aug 14 22:54:05 1992
From:       wright@bright.uoregon.edu "Charley Wright"
Date:       Fri, 14 Aug 92 22:54:05 +0200
Subject:    Re: Elements of order 4 in a subgroup of order 2

Dear Frank --

Thanks for straightening me out so promptly and patiently.  In fact I KNEW that I
needed a cgs for AgSubgroup, but somehow when I invoked it and GAP called the result a
subgroup I didn't stop to consider that I had misled GAP.

I feel especially foolish for having sent my "bug" report to GAP Forum, rather than to
you personally.  Perhaps someday I will learn to wait a day before sending off bug
reports.  In my defense let me say that a few years ago I really DID find serious bugs
in CAYLEY in exactly the kind of situation I reported to you.  The CAYLEY programmers
had overlooked what their programs would do in case composition factors had order 2.

All best wishes (=mfg),

Charley
-- 

wright@math.uoregon.edu

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

503-346-4730 (office)	503-485-4399 (home)



From neubuese@samson.math.rwth-aachen.de Sat Aug 15 11:11:14 1992
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Sat, 15 Aug 92 11:11:14 +0200
Subject:    use of the forum

In thanking Frank  Celler for straightening out a  misunderstanding in
the use of a GAP  funktion Charley  Wright  apologises for having sent
his question to the gap-forum.   I want to  emphazise that there is no
reason for such an  apology, in  fact I am grateful if such  questions
are made public rather than being discussed privately, since I am sure
that other  users are likely to run into similar problems and are such
alerted  to more subtle points. I want to encourage all  GAP users  to
make  bug reports but  also such  misunderstandings  known through the
GAP-forum, it  will always take some time until  bugs  get  fixed in a
patch and misunderstandings better prevented by additional warnings in
the manual. We may not always be able to react as fast as Frank did in
this  case and  we  ask  understanding  for  that, but  not  answering
immediately should  not  be interpreted as  unwillingness  to  answer.
There is no point at all to sweep such things under the carpet, to the
contrary it is the strong belief of all that are working to extend and
improve  GAP   that   they  should  be   known  in  order  to  prevent
disappointment in the use of GAP.

Joachim Neubueser



From werner@pell.anu.edu.au Sat Aug 15 14:10:10 1992
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Sat, 15 Aug 92 14:10:10 +0200
Subject:    Bug in list assignment ?

gap> L := [];
[  ]
gap> L[0] := 0;
Error, List assignment: <index> must be a positive int
gap> L[-1] := -1;
-1;
gap> L[-1000000] := 0;
Segmentation fault

Here is the bug fix:

*** list.orig	Sat Aug 15 22:00:18 1992
--- list.c	Sat Aug 15 22:07:39 1992
***************
*** 303,309 ****
  {
      TypHandle           hdList;         /* handle of the list              */
      unsigned long       type;           /* type of the list                */
!     unsigned long       ind;            /* index into the list             */
      TypHandle           hdElm;          /* handle of the selected element  */
  
      /* evaluate the list                                                   */
--- 303,309 ----
  {
      TypHandle           hdList;         /* handle of the list              */
      unsigned long       type;           /* type of the list                */
!              long       ind;            /* index into the list             */
      TypHandle           hdElm;          /* handle of the selected element  */
  
      /* evaluate the list                                                   */
***************
*** 391,397 ****
  {
      TypHandle           hdList;         /* handle of the list              */
      unsigned long       type;           /* type of the list                */
!     unsigned long       ind;            /* index into the list             */
      TypHandle           hdObj;          /* handle of the object            */
      unsigned long       l;              /* physical length of the list     */
  
--- 391,397 ----
  {
      TypHandle           hdList;         /* handle of the list              */
      unsigned long       type;           /* type of the list                */
!              long       ind;            /* index into the list             */
      TypHandle           hdObj;          /* handle of the object            */
      unsigned long       l;              /* physical length of the list     */
  
Werner Nickel
Mathematics Research Section
Australian National University



From fceller@bert.math.rwth-aachen.de Tue Aug 18 10:06:35 1992
From:       fceller@bert.math.rwth-aachen.de "Frank Celler"
Date:       Tue, 18 Aug 92 10:06:35 +0200
Subject:    Re: Checkpoint

In a letter to Volkmar Felsch Mike Newman says

NM> I hope there will be  some sort  of  checkpointing facility which will
MN> allow one to look at  big  presentations -  this does  not seem to  be
MN> routinely available in GAP which somewhat surprised me.

Since  we  think  that this a question that many other  might have  as
well, we post our answer in the gap-forum.

We think  what you  mean with checkpoints is  that  one  can break the
execution at prearranged points and save the workspace to disk.

Of these steps the first is possible. You can break gap using "CTRL-C"
or use interactive  functions like those  for  Tietze transformations.
The second step however does not exist,  yet.   What you can do is  to
send your  job  into  the background  after having  used "CTRL-C"  and
continue the next day.

If you need to logout  or want to change terminals you should  install
"screen" (a PD program) which  will give you pseudo terminals.   Using
this program you can break gap,  stay in the breakloop and detach your
terminal from the pseudo  terminal. It is possible to resume execution
at exactly the same point of the calculation. Of course GAP will still
use parts of the swap space this way.

On the other hand we intend eventually to have the possibility to save
the workspace, but it is not a trivial job to implement this and there
are more urgent tasks. Also of  course it is  nontrivial to decide how
far the  capabilities  of  such saving  the  workspace should go:  for
instance one might even want to  be able to  continue  on  a different
computer  (with maybe even a  different architecture),  but  more  one
requests here the more difficult is the job.

We hope the existing possibilities outlined above will do for all  you
need.

all the best
  Frank and Joachim



From neil@dehn.mth.pdx.edu Tue Aug 18 17:47:24 1992
From:       neil@dehn.mth.pdx.edu "John R. Neil"
Date:       Tue, 18 Aug 92 17:47:24 +0200
Subject:    Load time for libraries...

I was wondering what the possibilities were for have the option of
byte-compiling the gap libraries.  It is somewhat annoying to have to wait
each time a new routine is called upon to have gap interpret a text file.
In addition, of course, byte-compiling would also provide opportunities to
optimize the code somewhat leading to potentially faster execution times.
Of course, the optimal solution for time would be to have a dynamically
linked library in the machine code of the computer it runs on.  Of course this
is a much more complicated task and makes the portability of GAP more
problematical.  However, it is an attainable goal, I think.

I have looked into the parsing routines in the source code but have not had
enough time to see exactly how the parsing process proceeds to determine how
easy or hard it would be to include byte-compiling.  It should just be a
matter of saving the internal format of the code and data structures
associated with it to disk and then recalling them when the library is needed.
This is exactly the manner in which emacs operates.  And in emacs you even
have a choice as to whether or not you desire to have the libraries byte-
compiled or not and having both around does not pose any particular problem.

Anyway, that's just my two cents worth for improving the efficiency of what
I think is a fabulous system.

--John Neil

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



From werner@pell.anu.edu.au Wed Aug 19 04:41:19 1992
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Wed, 19 Aug 92 04:41:19 +0200
Subject:    Re: Checkpoint

In their comment on the issue of `checkpoints' in GAP Frank Celler and
Prof. Neubueser don't mention a point that I find very important.
If one runs a calculation that might take several weeks (or even months)
of CPU time, it is crucial to have the possibility to save the current
status of a computation at a given time. The reasons why it is so crucial
is simple: During the calculation the system might crash, be taken down
for maintenance or GAP might run out of memory and one would like to
continue the computation at a time when the system is less busy. Checkpoints
would simply be a safeguard against the various uncertainties that might
occur during a long calculation. For this purpose it is not necessary to
have a very flexible way of saving the GAP workspace; I don't think that
portability across different computer architectures is really an issue.

I am aware of the fact that it is not trivial to implement a checkpoint
facility, but I think a very simple one, that supports people in doing
extensive calculations, is better than none.

I am very interested to hear other people's opinion on this matter.

Regards, Werner Nickel.



From lstiller@goshawk.lanl.gov Wed Aug 19 13:00:56 1992
From:       lstiller@goshawk.lanl.gov "Lewis Stiller"
Date:       Wed, 19 Aug 92 13:00:56 +0200
Subject:    GAP vs. CAYLEY

How would folks compare CAYLEY vs. GAP power?

Lewis Stiller
Center for Nonlinear Studies
MS B258
Los Alamos National Laboratory
Los Alamos, NM 87545
FAX: 505-665-2659



From martin@bert.math.rwth-aachen.de Thu Aug 20 12:58:51 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 20 Aug 92 12:58:51 +0200
Subject:    Re: Re: Checkpoint

Mike Newman writes in his e-mail message:

    I hope there will be some sort of checkpointing facility which will
    allow one to look at big presentations - this does not seem to be
    routinely available in GAP which somewhat surprised me.

Let me first provide my definition of a checkpoint, so that you can make
sure we are talking about the same thing.

    A *checkpoint* allows a user of a computer system to undo or cancel
    everything the system has been doing since the time the checkpoint
    was passed.  (Note that usually only internal changes of the state
    are undone.  External changes, such as writing to external files,
    are usually not undone.)

For example, suppose you are playing a computer adventure game.  You are
about to drink a potion you just found.  However, you are not certain
that this is a good idea.  So you insert a checkpoint.  Then you try the
potion.  If it turns out that the potion is lethal, you undo everything
back to the checkpoint and put the potion in your bag (to offer it to
monsters later).

For a more serious example, suppose you are working with a big
presentation in GAP.  You are about to replace a certain generator by a
word in the other generators.  However, you are not certain that this is
a good idea.  If GAP supported checkpoints, you could now simply insert
one.  Then you could try the substitution.  If it turns out later that
this was not a good idea, you could undo everything back to the
checkpoint and could try another substitution.

One way to implement checkpoints is to journal all commands the user
issued, and to remember how each of them changed the state of the system.
To go back to a checkpoint you go backwards through the history, undoing
every single step.  Some editors do this.

The more usual way to implement checkpoints is to save the state of the
system as a workspace file.  To go back to the checkpoint you can then
simply load this workspace file.

I think this is what Mike had in mind.  Certainly Frank and Joachim
understood it this way, because they wrote:

    We think what you mean with checkpoints is that one can break the
    execution at prearranged points and save the workspace to disk.

With workspaces it would also be possible to save the state of a
computation to a file, log out, go home, come back the next evening, log
on, start GAP again, and continue the computation by loading the
workspace.  Note that this has very little to do with checkpoints.
Frank and Joachim show that most of this effect can be achieved
without workspaces:

    If you need to logout or want to change terminals you should install
   'screen' (a PD program) which will give you pseudo terminals.  Using
   this program you can break GAP, stay in the breakloop and detach your
   terminal from the pseudo terminal.  It is possible to resume execution
   at exactly the same point of the calculation.  Of course GAP will
   still use parts of the swap space this way.

Sidenote 1:  there are many ways you can *break* GAP,
             but what you mean here is to *interrupt* GAP (I hope ;-)
Sidenote 2:  some users achieve this by simply refusing to lock out ;-)

Werner Nickel points out that there is even another use for checkpoints:

    In their comment on the issue of `checkpoints' in GAP Frank Celler
    and Prof. Neubueser don't mention a point that I find very important.
    If one runs a calculation that might take several weeks (or even
    months) of CPU time, it is crucial to have the possibility to save
    the current status of a computation at a given time. The reasons why
    it is so crucial is simple: During the calculation the [computer]
    system might crash, be taken down for maintenance, or GAP might run
    out of memory and one would like to continue the computation at a
    time when the system is less busy.  Checkpoints would simply be a
    safeguard against the various uncertainties that might occur during a
    long calculation.  For this purpose it is not necessary to have a
    very flexible way of saving the GAP workspace; I don't think that
    portability across different computer architectures is really an
    issue.

Precaution against uncertainties is the main reason for checkpoints
in commercial database systems.  For this to work it is important
that the state is save at some place that is not volatile, e.g.,
on a workspace file.

After repeating all this stuff let me now finally come to my own
comments.

For presentations something like checkpointing this is actually possible.
A presentation (in GAP 3.2, 3.1 doesn't allow you to work with
presentation, only with finitely presented groups) is represented by a
record.  If you work with the presentation, e.g., if you replace one
generator by a word in the other generators, you change this record.  So
what you can do is the following.  Before trying something, you simply
make a copy of the presentation record.  If it turns out that what you
did was not a good idea, you simply throw away the presentation record
and continue to work with the copy.

Implementing workspaces is not a trivial task.  How difficult it really
is depends on the features it should provide.  To find out what exactly
you want, I submit the following questionaire.  Please do take the time
to fill it out.  For each feature replace the 'O' with 'Y' (yes), 'N'
(no), or 'X' (don't care).  Please send you answer as e-mail message
to me.  I will summarize the answers in this forum.

O  It should be possible to save the current state of GAP to a workspace
   file and load it later back into GAP.

O  It should be possible to load a workspace file back into a GAP that
   was started with different options, e.g., a different amount of
   working memory.

O  It should be possible to load a workspace file back into a different
   version of GAP, e.g., it should be possible to load a 3.1 workspace
   back into GAP 3.2.

O  It should be possible to move workspace files between different
   computers, e.g., it should be possible to save a workspace on a
   DECstation and load it back on a Sun.

O  It should be possible to create a workspace file not only when you
   see the 'gap>' prompt, but also from within functions and from the
   break loop (this is probably very difficult).

O  It should provide the following additional features:
   ____________________________________________________

Martin.

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



From martin@bert.math.rwth-aachen.de Thu Aug 20 15:59:07 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 20 Aug 92 15:59:07 +0200
Subject:    Re: Various suggestions

Please ignore my previous post, I accidently mailed it before it was
complete.  [Previous post removed from archive]

Quite a while ago Steve Linton made various suggestions.  I want to make
some remarks.  Generally most of them seem reasonable.  However, please
don't expect those feature to show up in the next release.

Steve write:

    It would be nice to be able to access the operating system
    environment from GAP. A function Getenv(string) perhaps and/or an
    array Environment of pairs of strings.

What about a record?  'ENVIRONMENT.USER' would evaluate to '"sl25"'.
Actually a function like 'Getenv' is probably safer, because I am not
certain that all systems support 'environ'.  Anybody knows what ANSI has
to say about this?

Steve continues:

    It would be nice to have a structure that behaved like a hash-table
    or a PERL associative array. This would enable general Orbit
    algorithms to go MUCH faster. More generally Aho, Hopcraft and Ulmann
    (Design and Analysis...) has a nice general description of
    'dictionaries' in terms of which operations can be carried out
    quickly. A set of constructs implementing these would be extremely
    useful.

This is clearly the most ambitious suggestion.  I agree that hash-tables
or associative arrays would be very nice.  What I would really like to
have in GAP are *tables*, which are basically mappings from arbitrary
keys to values.  A table where all keys are positive integers is a list,
a table where all keys are strings is a record.  Very elegant, very
powerfull.

The problem is the implementation.  In GAP 2.4 we used hashing for sets.
We had problems to come up with a reasonable hash function that worked
well for all possible keys.

Such a hash function would have to look at all the bytes of an object to
compute the hash value.  To see this imagine a hash function that only
looks at the first 32 bytes of an object.  If this hash function is used
on a list of permutations that all lie in the stabilizer of [1..16] it
would hash all to the same value.

On the other hand look at the following rather common case.  Suppose we
have a list of 1000 permutations of degree 1000 and suppose that [1..5]
is a base, e.g., no two permutations map [1..5] to the same images.  Then
the binary search does 10 comparisons of permutations, and for each
comparison of permutations it compares at most 5 images.  So it looks at
10 * 5 * 2 = 100 numbers.  But the hash function must look at all 1000
numbers of the permutations that is looked up.  So the binary search is
actually faster in this case.

Another problem with hash functions is that there are objects in GAP that
are equal, but are represented differently.  So the hash function cannot
simply be a function of the representation (i.e. of the sequence of bytes
used to represent an object).

This is not to say that tables could not be made to work efficiently.
However, clearly this area needs more investigation.  Maybe we can learn
more from the Maple people; Maple uses hashing all the time.

Steve continues:

    Especially on PCs (I don't know about STs) repeated use of AppendTo
    is very slow as the file has to be closed and the directory updated
    between each call. It would be nice to have fopen, fread/write and
    fclose -like calls using some sort of file handle.

There will be better support for I/O when GAP finally gets the
facilities to communicate with subprocesses.  This will also solve
this problem (and some others as well).  This will be some Scheme
stream like facility (instead of C like handles).

Steve continues:

    It would be nice to be able to control the level of printing when
    entering a break loop. When the progran is in a recursive procedure
    or something I often loose the piece of information I want off the
    end of the traceback.

I am not certain that I understand this request.  Doesn't 'Backtrace'
do what you want?  Umm, I see now.  'Backtrace' is not documented.
Ok, here is a description of 'Backtrace'.  Hope this helps.

    'Backtrace()'
    'Backtrace( <level> )'

    'Backtrace' can be used inside a break loop to print  a  history  of  the
    computation.  'Backtrace' prints a list of  all  active  functions,  most
    recent first, up to maximal <level>  nestings.  If  <level>  is  positive
    the *expressions* of the arguments of the functions  calls  are  printed,
    otherwise the *values* of  the  actual  arguments  are  printed  instead.
    <level> default to 5, i.e., calling 'Backtrace'  with  no  argument  will
    print the 5 most recent functions with the expressions of the arguments.

    When a break loop (see "Break Loops") is entered  'Backtrace'  is  called
    automatically.

Steve continues:

    Also for debugging purposes, it would be nice to be able to look past
    a local variable at a 'hidden' variable of the same name in an outer
    scope. Either some way of saying 'The global x' and the 'the x
    belonging to procedure foobar' (though what happens if foobar is
    recursed 8 levels deep?) or of saying 'The x in the scope outside
    this one'.

There will be functions 'NextEnvironment' and 'PrevEnvironment',
which will allow you to step up and down the stack.  Each local variable
will then be searched on that level.  So to find 'foobar' 8 levels deep
you write 'NextEnvironment(8); foobar; PrevEnvironment(8);'.

Steve continues:

    Possibly the read-eval-print loop should suppress or abbreviate the
    printing of very long results.

Could you elaborate this a little bit more?  On what should it depend
whether GAP suppresses the output?  Do you want GAP to detect that the
output is going to be longer than 300 lines, and suppress it?

Martin.

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



From sl25@cus.cam.ac.uk Thu Aug 20 18:02:51 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Thu, 20 Aug 92 18:02:51 +0200
Subject:    Re: Various suggestions 

> Quite a while ago Steve Linton made various suggestions.  I want to make
> some remarks.  Generally most of them seem reasonable.

Thanks

>  However, please
> don't expect those feature to show up in the next release.

Don't worry. I half had in mind to implement some of them myself, but I thought I'd
float the ideas for consideration first.

> 
> Steve write:
> 
>     It would be nice to be able to access the operating system
>     environment from GAP. A function Getenv(string) perhaps and/or an
>     array Environment of pairs of strings.
> 
> What about a record?  'ENVIRONMENT.USER' would evaluate to '"sl25"'.
> Actually a function like 'Getenv' is probably safer, because I am not
> certain that all systems support 'environ'.  Anybody knows what ANSI has
> to say about this?

A record is clearly correct from a GAP viewpoint, however a quick lok
at the Norcroft
library spec suggests that environ is not required by ANSI.

> 
> Steve continues:
> 
>     It would be nice to have a structure that behaved like a hash-table
>     or a PERL associative array. This would enable general Orbit
>     algorithms to go MUCH faster. More generally Aho, Hopcraft and Ulmann
>     (Design and Analysis...) has a nice general description of
>     'dictionaries' in terms of which operations can be carried out
>     quickly. A set of constructs implementing these would be extremely
>     useful.
> 
> This is clearly the most ambitious suggestion.  I agree that hash-tables
> or associative arrays would be very nice.  What I would really like to
> have in GAP are *tables*, which are basically mappings from arbitrary
> keys to values.  A table where all keys are positive integers is a list,
> a table where all keys are strings is a record.  Very elegant, very
> powerfull.

This isn't quite all-powerful. It would also be desirable to be able to get
at the keys in some order (think of heap-sort).

> 
> The problem is the implementation.  In GAP 2.4 we used hashing for sets.
> We had problems to come up with a reasonable hash function that worked
> well for all possible keys.
> 
 [ ... more problems with hash functions ... ]

I see the problem with hash functions, perhaps yuou could hash long
lists (permms, etc.)
on certain selected entries (first 10, plus a (pre-chosen) random one from each
subsequent 10 up to 100, etc., etc. However, possibly hashing is not
the right way to go.

Have you considered something like a B-tree or a 2,3-tree (in Knuth and AHU
respectively)? This will cost you log n on a lookup, but simply dpends on having
fast 3-way comparison. This also allows recovery in order.

> This is not to say that tables could not be made to work efficiently.
> However, clearly this area needs more investigation.  Maybe we can learn
> more from the Maple people; Maple uses hashing all the time.

Indeed, I wonder how they cope when you generate all elements of GF(2)^16.


> 
> Steve continues:
> 
>     Especially on PCs (I don't know about STs) repeated use of AppendTo
>     is very slow as the file has to be closed and the directory updated
>     between each call. It would be nice to have fopen, fread/write and
>     fclose -like calls using some sort of file handle.
> 
> There will be better support for I/O when GAP finally gets the
> facilities to communicate with subprocesses.  This will also solve
> this problem (and some others as well).  This will be some Scheme
> stream like facility (instead of C like handles).

Great

> 
> Steve continues:
> 
>     It would be nice to be able to control the level of printing when
>     entering a break loop. When the progran is in a recursive procedure
>     or something I often loose the piece of information I want off the
>     end of the traceback.

[.. Description of backtrace omitted ...] 

That is just what I needed. It would be nice if the default level for backtrace
were taken from some global variable (or settable by function call).

> 
> Steve continues:
> 
>     Also for debugging purposes, it would be nice to be able to look past
>     a local variable at a 'hidden' variable of the same name in an outer
>     scope. Either some way of saying 'The global x' and the 'the x
>     belonging to procedure foobar' (though what happens if foobar is
>     recursed 8 levels deep?) or of saying 'The x in the scope outside
>     this one'.
> 
> There will be functions 'NextEnvironment' and 'PrevEnvironment',
> which will allow you to step up and down the stack.  Each local variable
> will then be searched on that level.  So to find 'foobar' 8 levels deep
> you write 'NextEnvironment(8); foobar; PrevEnvironment(8);'.

	Excellent.

> 
> Steve continues:
> 
>     Possibly the read-eval-print loop should suppress or abbreviate the
>     printing of very long results.
> 
> Could you elaborate this a little bit more?  On what should it depend
> whether GAP suppresses the output?  Do you want GAP to detect that the
> output is going to be longer than 300 lines, and suppress it?
> 

Ideally yes. It doesn't have to be perfect, but simply printing long lists as
for example

[2,3,5,7,11, <28 ommitted> ,139,149]

and printing long permutations as

<permutation of 10000 points>

would be very nice. Obviously, such should be optional, and controllable in degree.
Ideal, but probably harder would be to control the level of
abbreviation independently
for console output and logfile. Also, when printing nested lists and structures, the
level of abbreviation should probably increase as the level of nesting increases.

This should I think, only apply to the actual read-eval-print loop. Actually calling
Print should always do the whole job, thus Print(last); will always
recover whatever was
abbreviated. 

Basically I often forget to use ;; and get 60 permutations on 300
points scrolling past.


	As I said, I don't and didn't expect Martin and his team to
implemnt any of this
	in any particular hurry, I just had some ideas that seemed worth discussing.

		Steve

PS The latest version of DJGPP allows control-C trapping (I think) so a version
of GAP/386 with proper ^C handling should be out soon.



From martin@bert.math.rwth-aachen.de Tue Aug 25 22:41:43 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 25 Aug 92 22:41:43 +0200
Subject:    Re: Load time for libraries...

About a week ago John Neil wrote an e-mail to the GAP forum asking about
the possibilities of byte compiling the library.

There are two different issues addressed in his e-mail, which I like to
discuss a little bit.  First let us take a look at the libraries and the
time it takes to load them.  Then in another e-mail I will discuss the
issue of the interpretation of GAP programs.

When you start GAP, it only reads '<gap-dir>/lib/init.g'.  This file does
not contain any library functions (except some random stuff like
'ReadLib', 'ReadGrp', etc.).  However, it contains lines of the form

    AUTO( ReadLib( "combinat" ),
      Factorial, Binomial, Bell, Stirling1, Stirling2, CombinationsA,
      ... );

Such a statement makes the declares the functions (actually variables)
'Factorial', 'Binomial', etc.  When such a variable, e.g., 'Factorial', is
evaluated GAP executes the statement 'ReadLib("combinat");'.  This
statement will cause the file '<gap-lib>/lib/combinat.g' to be read, which
in turn contains the definition of 'Factorial' etc.  The next time
'Factorial' is called it is already read, and need not be read again.

This does *not* take very long.  On the DECstation 5000/120 I am using,
reading 'combinat.g' takes about 350 msecs.  Note that 'combinat.g' is a
file with 1500 lines, defining 56 functions.

Of course you all know that there must be more to it, because you all know
that something as simple as 'Group( (1,2), (1,2,3) )' will take more than
5 secs for the first time.  The problem is that this simple statement will
cause a lot of files to be read.  If you want to trace this, set
'InfoRead1:=Print;' before executing 'Group( (1,2), (1,2,3) )' (I have
this set in my '.gaprc' file).  This will give the following output (the
indentation is used to show which file is read from within which other
file.  For example 'grphomom' is read from within 'group', and in turn
reads 'mapping'.)

    #I  ReadLib( "group" )
    #I    ReadLib( "domain" )
    #I    ReadLib( "grpelms" )
    #I    ReadLib( "grphomom" )
    #I      ReadLib( "mapping" )
    #I    ReadLib( "operatio" )
    #I    ReadLib( "grpcoset" )
    #I    ReadLib( "grpprods" )
    #I    ReadLib( "lattgrp" )
    #I  ReadLib( "group" ) done
    #I  ReadLib( "list" )
    #I  ReadLib( "list" ) done
    #I  ReadLib( "permutat" )
    #I    ReadLib( "permgrp" )
    #I      ReadLib( "permoper" )
    #I      ReadLib( "permbckt" )
    #I      ReadLib( "permnorm" )
    #I      ReadLib( "permhomo" )
    #I      ReadLib( "permprod" )
    #I      ReadLib( "lattperm" )
    #I  ReadLib( "permutat" ) done

Those files account together for 23500 lines, and about 700 Kbyte.  If one
looks closer at the profile one sees that about 30 % of the 5 secs are
spend reading the text files.  This part could be improved by about a
factor of 2.  Another 30 % are spent in the scanner assembling the single
characters into symbols.  This part could also be improved by a factor of
2.  (This figures. 'wc', which does something somewhat simpler, needs
about 1 second to count the lines, words, and characters in those files).
The final 30 % are spent in the reader building the syntax trees.  I see
no easy way to improve the performance of this part.  Thus the whole time
could be reduced to about 3--4 seconds.

Now let us compare this with EMACS, which Neil mentiones in his e-mail.
EMACS takes about 16 seconds to read the file 'gnus.el' 3 times, which
amounts to about the same number of lines and bytes.  Bytecompiling this
file and loading the byte compiled file 3 times still takes about 8
seconds.

The point I want to make is that it is not the mechanism by which GAP
reads its library that makes this process slow.  It is the pure amount of
code in the library.  The total GAP library is currently about 86000 lines
and 2.8 MBytes.  This is larger than the EMACS library (which, as of
version 18.58, is about 61000 lines and 2.2 MByte, including stuff like
'ada.el', 'vi.el', 'vip.el', etc.).  And while you do most of your editing
with only a few of the library files of EMACS, almost any nontrivial
application of GAP will use (read) about half of the library.

Thus simply saving the syntax trees GAP builds to a disk file and
recalling them when needed would not help that much.  Also note that this
is not what EMACS does.  EMACS's byte compiled files contain the bytecode
for each function proper.  However, they also contain the name of the
function defined, the description string of this function, and the
constant vector.  In fact the bytecode is usually only a small part of
such a definition.  I think that the most important reason why EMACS's
byte compiled files are read in faster than the corresponding source files
is that they contain no comments.

This is of course also an option for GAP.  Take the library and remove all
the comments and unnecessary blanks.  However, the effect is not that
dramatic.  While the space is reduced by a factor of 2, the time is
reduced from 5.3 seconds to 4.3 seconds.  This is probably because the
part of the scanner that drops the comments is pretty efficient.

Anyhow, there is another option, which EMACS and TeX use.  One could load
(most) of the library, and then dump a core file.  Then you modify this
core dump file (in an unfortunately very operating system dependent way)
and obtain a new executable.  When you execute this file all the parts of
the library that where loaded when you produced this core dump will be
automatically loaded again.  This is very much faster, because no
processing needs to be done at all, and also because the routines in the
UNIX kernel that copy a file into memory for execution are pretty much
optimized.  We are investigating this possibility further, also in
connection with workspace files.

Tommorow more on the issue of interpreting GAP programs.

Martin.

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



From maspr@lux.levels.unisa.edu.au Wed Aug 26 04:45:03 1992
From:       maspr@lux.levels.unisa.edu.au "Simon Paul Ronald"
Date:       Wed, 26 Aug 92 04:45:03 +0200
Subject:    How do I deregister from GAP forum?

Hi,

	I was wondering if you could tell me how I deregister
from the GAP forum,

	I haven't been using it as much as I though.

Thanks - Simon.



From sl25@cus.cam.ac.uk Wed Aug 26 15:50:19 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Wed, 26 Aug 92 15:50:19 +0200
Subject:    Re: Load time for libraries... 

What Martin says on this is true for UNIX systems, however
PCs generally have smaller slower hard disks and less efficient
disk handling in the OS. Accordingly, I have found it quite useful
to strip the libraries of comments and spurious space.  I have a
small PERL program to do this if anyone wants it.

There is an additional benefit of the load and dump technique
used by EMACS and TeX, which is that, with a little care, most of
the loaded libraries can be marked as 'pure' code, never altered
by the program. This enables multiple users to share a single
copy in memory.

		Steve 



From martin@bert.math.rwth-aachen.de Thu Aug 27 11:37:12 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 27 Aug 92 11:37:12 +0200
Subject:    Re: Load time for libraries...

Yesterday I wrote about the loading  of  the libraries.  In this e-mail I
will discuss the interpretation of GAP programs.

When a GAP function is read into GAP, the reader builds the syntax tree
for the function.  Such a syntax tree consists of a number of nodes, one
for each operator or syntactic construct.  Each node has the operands as
descendants.  For example one could picture the syntac tree for the
statement

    if a < 0  then a := b + 2 * a; fi;

as follows

          if
         /  \
        <    \
       / \    \
      a   0    :=
              /  \
             a    +
                 / \
                b   *
                   / \
                  2   a

This statement is executed by evaluating this syntax tree in a *recursive
descent* way.  Let us look a little bit closer at this.  First 'EVAL' is
called and the entire tree is passed as argument.  'EVAL' sees that the
type of the root node is 'if' (actually 'T_IF', which is 49), and calls
the function 'EvIf', again passing the tree as argument.  'EvIf' first
calls 'EVAL' recursively, this time passing the subtree for 'a < 0' as
argument.  'EVAL' will call 'EvLt' (less than) and so on.

Now if GAP had a bytecode interpreter, things would work a little bit
different.  Then a translator would produce code for an abstract
bytecode machine from the syntax tree.  For example for the above
syntax tree it might produce something like

        push-var a          ; push the value of the variable a
        push-const 0        ; push the constant 0
        less-than           ; stack a 0 -> stack <result of a < 0>
        branch-if-false l0  ; jump to label l0 if the result is false
        push-var b
        push-const 2
        push-var a
        mult
        add
        store-var a         ; store the result in the variable a again
    l0: <code for next statement>

The abstract machines used in such schemes are usually stack machines (it
is interesting to speculate why stack machines, which are not used any
more in hardware processor designs, are still quite popular for bytecode.
I think the reason is that it is not possible to do several things in
parallel in software.  In other words, the reason is that there is no
software equivalent of the *<n>-ported register file*).  Those
machines usually have 256 (or less) instructions, so the instructions can
be stored in one byte each, hence the name.

This byte code is then interpreted by an abstract machine.  This machine
is usually implemented by a large function, which basically looks as
follows

    interpret ()
    {
        while ( 1 ) {
        switch ( *pc++ ) {
        case push-var:  *sp++ = **(object**)pc;
                        pc += 4;
                        break;
        case add:       sp[-2] = sp[-2] + sp[-1];
                        sp--;
                        break;
        ...
        }
        }
    }

Except of course the true code is more complex, because it must test the
types of the operands of the 'add', test whether an overflow occurred,
etc.  There are slightly different methods to implement the abstract
machine, but it usually does not make much difference.

One can argue that interpreting the syntax tree is not that much
different from having an abstract machine interpret bytecode.  Namely the
type of each node is the bytecode, i.e., an instruction of an abstract
machine, and the children of this node are the operands of this
instruction.  So the main difference is that the operand expressions can
become arbitrarily complex.

Now we think that a true bytecode implementation can be faster by about
a factor of 4 than the recursive descent evaluator currently in GAP.
But for this factor of 4 the following optimizations must be made

*   The instructions of the abstract machine must be carefully selected
    to ensure that common operations can be executed with only a few
    instructions.  For example there should be an instruction to
    increment the value on the stack top by one, because statements
    such as 'i := i + 1;' are very common.

*   The C compiler must do a reasonable job of optimizing the function
    'interpret'.  For example, 'pc' and 'sp' (which need to be global
    variables) should be allocated registers and only spilled to memory
    when necessary, the 'switch' statement should be compiled to code
    that uses a jump table, etc.  (Those optimizations where not
    available in the compilers we used when we started with GAP.)

*   The translator, which translates the syntax tree into the bytecode,
    must perform some optimizations.  For example in a statement such as
    'if S.orbit[1]^g = S.orbit[1] then ...' the value of 'S.orbit[1]'
    should be evaluated only once.

When we started GAP we decided that we had enough work to do and that we
simply had not enough manpower (and know-how about bytecode interpreters)
to spent too much time on the implementation of the programming language.
So we decided to use the simpler recursive descent implementation.

Now one might want to reevaluate this decision, since the situation is
not the same as it was 6 years ago.  We now have data about real GAP
programs.  This data (and several thought experiments) give me a fairly
good idea on how a bytecode instruction set architecture for GAP should
look.  The C compiler are much better than they were 6 years ago.  A lot
more about optimization is known, so that it is quite clear how to
perform common subexpression elimination, etc.

So thinking about writing a bytecode interpreted for GAP might now be a
reasonable thing to do, except there is an even better option, which we
are investigating currently.  This works as follows.  You take the GAP
code and compile it to C code.  Then you call the native C compiler to
compile this to machine code and link this to the GAP kernel.  This idea
is used in implementations of LISP (KCL) and Scheme (Scheme->C) with very
good results.  It has several advantages.  First it is quite portable.
Second the result is machine code, which is executed without the overhead
of an interpreter (such as the one needed for a bytecode system).  Third
the C compiler will take care of many optimizations, e.g., most C
compilers nowadays perform common subexpression elimination.  So one can
concentrate on other optimizations, such as determing the types of
objects at compile time instead of runtime.

As I said we are investigating this possibility.  We hope that we will be
able to achieve a performance an order of magnitude better than the
current implementation.  Of course this estimate is only valid for
functions that spent most of there time with simple operations such as
addition of integers, indexing into lists, etc.  Functions such as the
Schreier-Sims algorithm, which spents most of its time multiplying
permutations, will not benefit that much.  Note that I cannot make any
statements about when such a compiler might be available (except that it
will certainly not be this year ;-).

Martin.

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



From martin@bert.math.rwth-aachen.de Thu Aug 27 17:38:48 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 27 Aug 92 17:38:48 +0200
Subject:    Tables (was Re: Various suggestions)

In my e-mail of 20-Aug-92 I write (among other things):

    What I would really like to have in GAP are *tables*, which are
    basically mappings from arbitrary keys to values.  A table where all
    keys are positive integers is a list, a table where all keys are
    strings is a record.  Very elegant, very powerfull.

In his e-mail of 20-Aug-92 Steve Linton answers:

    This isn't quite all-powerful. It would also be desirable to be able
    to get at the keys in some order (think of heap-sort).

This comment does not make any sense to me.  Could you please explain it?
There probably would be some function 'Keys( <table> )', which would
return the *set* of key values.  For an arbitrary *list* <l> this would
be a (sorted) list of positive integers, for a dense list it would in
fact be a range.  Then for an arbitrary table <table> writing
'Sublist(<table>,Keys(<table>))' (or '<tab>{ Keys( <tab> ) }') would give
you the *values* in the table in the order implied by the keys.  Is this
what you mean?

Steve continues:

    [...] However, possibly hashing is not the right way to go.

    Have you considered something like a B-tree or a 2,3-tree (in Knuth
    and AHU respectively)?  This will cost you log n on a lookup, but
    simply dpends on having fast 3-way comparison. This also allows
    recovery in order.

The cost of doing a lookup in those trees is about the same as doing
a lookup in a sorted list.  The advantage of those trees is of course
that insertion and deletion have cost $O(log(n))$, while insertion
and deletion from a sorted list is a $O(n)$ operation.  On the other
hand, finding the <i>-th element in such a tree is also an
$O(log(n))$ operation, while it is an $O(1)$ operation in a sorted
list.

Martin.

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



From nick@siucbal.c-cs.siu.edu Thu Aug 27 17:56:21 1992
From:       nick@siucbal.c-cs.siu.edu "Nick Phillips"
Date:       Thu, 27 Aug 92 17:56:21 +0200
Subject:    missing tex font

I can't print the manual because I'm missing a tex font called 
cmbx10.681.pk.
Can anyone help me?  This is on a SUN Sparcstation.
Nick Phillips.



From martin@bert.math.rwth-aachen.de Thu Aug 27 19:01:11 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 27 Aug 92 19:01:11 +0200
Subject:    Re: missing tex font

Nick Phillips writes:

    I can't print the manual because I'm missing a tex font called 
    cmbx10.681.pk.
    Can anyone help me?  This is on a SUN Sparcstation.

'cmbx10' stands for computer modern boldface extended.  This is the
ordinary boldface font (in spite of the ``extended'', there simply is no
``unextended'' boldface).  In the GAP manual this font is used for

    boldface text                       (cmbx10.300pk)
    section titles                      (cmbx10.432pk)
    chapter titles                      (cmbx10.746pk)
    the string ``Chapter <nr>''         (cmbx10.622pk)

The numbers in parenthesis are the files needed for our 300 dpi HP
LaserJet III.  So 'cmbx10.681pk' is a peculiar resolution.  What kind of
output device is this for?

What is also peculiar is that this will keep you from printing the file.
Our 'dvi' driver would simply substitute another similar font, and I
assumed that other 'dvi' drivers would do this as well.

Also a while ago David G. Cantor wrote us that he had trouble because the
manual used bold typewriter fonts, which were not available on his
machine.  We have remove the use of bold non-roman fonts with the first
upgrade.  So if you haven't already applied this upgrade, this might be
worth a try.

If all this doesn't help one should simply create the new font file
with METAFONT.  Do you have METAFONT available on your machine?
If not I would be willing to help you, but I will be away next week.
Maybe somebody else reading this forum can help him?

Martin.

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



From ffor@gauss.math.rochester.edu Thu Aug 27 19:38:53 1992
From:       ffor@gauss.math.rochester.edu "Jackie Ford"
Date:       Thu, 27 Aug 92 19:38:53 +0200
Subject:    missing tex font

   Date: Thu, 27 Aug 92 19:01:30 +0200

       I can't print the manual because I'm missing a tex font called 
       cmbx10.681.pk.
       Can anyone help me?  This is on a SUN Sparcstation.

If you have MetaFont available on your machine I would send you the
MetaFont source. You can contact me directly at

	ffor@gauss.math.rochester.edu

Frederick Ford



From geoff@math.ucla.edu Fri Aug 28 06:50:38 1992
From:       geoff@math.ucla.edu "Geoffrey Mess"
Date:       Fri, 28 Aug 92 06:50:38 +0200
Subject:    

I would appreciate information on this error message:

gap: panic 'SyGetmem' detected corrupted heap!

This occurred while computing the core of an index 81 subgroup in a  
finitely presented finite group. I hope the next edition of the  
manual will have "panic" in the index.

Geoffrey Mess



From martin@bert.math.rwth-aachen.de Fri Aug 28 10:20:46 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Fri, 28 Aug 92 10:20:46 +0200
Subject:    Re: 

In his e-mail message of 28-Aug-92 Geoffrey Mess writes

    I would appreciate information on this error message:

    gap: panic 'SyGetmem' detected corrupted heap!

    This occurred while computing the core of an index 81 subgroup in a  
    finitely presented finite group. I hope the next edition of the  
    manual will have "panic" in the index.

What happens is the following.  GAP begins with a certain amount of
main memory (e.g., 2 Megabytes).  This memory is usually allocated
with the UNIX system call 'sbrk'.  So the memory looks as follows.

    +--------------------------------+
    | GAP Workspace                  |
    +--------------------------------+

Now GAP works for a while.  Some operations (probably reading files of
the library) causes GAP to call a C library function (which is linked
into the GAP kernel) that also needs some memory.  This memory is
allocated with the C library function 'malloc', which in turn also calls
'sbrk'.  So now the memory looks as follows.

    +--------------------------------+----------------+
    | GAP Workspace                  | 'malloc' Arena |
    +--------------------------------+----------------+

Then GAP needs more memory to continue with whatever it is doing.  To get
more memory it tries to extend the workspace with 'sbrk'.  Now GAP
notices that it cannot extend the workspace, because the memory adjacent
to the workspace is already used.  GAP reacts with the (not very
desriptive error message)

    gap: panic 'syGetmem' detected corrupted heap!

The solution (well at least a workaround) is quite simple.  Start GAP
with more memory (using the '-m' option).  To see how much memory GAP is
needing you can use the '-g' option.

One thing is strange.  I understood that you were working on a NeXT.  I
thought the problem could not happen on the NeXT (because 'sbrk' is not
used on the NeXT).  I will check with the Frank, who did the NeXT port,
when he returns from his holidays.

Martin.

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



From boris@mathematik.uni-bielefeld.de Fri Aug 28 13:34:39 1992
From:       boris@mathematik.uni-bielefeld.de "Boris Hemkemeier"
Date:       Fri, 28 Aug 92 13:34:39 +0200
Subject:    Re: missing tex font

>    Nick Phillips writes:
> 
>        I can't print the manual because I'm missing a tex font called 
>        cmbx10.681.pk.
>        Can anyone help me?  This is on a SUN Sparcstation.

I produced a PostScript version of the updated (patch level 2) gap
manual. Available via anonymous ftp on 
ftp.mathematik.uni-bielefeld.de:/pub/math/gap/gap-manual-3r1-pl2.ps.Z
(1119715 Bytes).

Boris H.
-- 
			  "Say no to bugs!"
Boris Hemkemeier	boris@mathematik.uni-bielefeld.de.



From sl25@cus.cam.ac.uk Thu Sep  3 12:40:14 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Thu, 3 Sep 92 12:40:14 +0200
Subject:    Re: Tables (was Re: Various suggestions) 

Tables and keys:

Sorry I was unclear here. The thing is that in a hash-table,
find-first and related operations that depend on the ordering of
the keys are slow (O(n) or O(n log n)), whereas in a tree type
structure they are O(log n).

> Steve continues:
> 
>     [...] However, possibly hashing is not the right way to go.
> 
>     Have you considered something like a B-tree or a 2,3-tree (in Knuth
>     and AHU respectively)?  This will cost you log n on a lookup, but
>     simply dpends on having fast 3-way comparison. This also allows
>     recovery in order.
> 
> The cost of doing a lookup in those trees is about the same as doing
> a lookup in a sorted list.  The advantage of those trees is of course
> that insertion and deletion have cost $O(log(n))$, while insertion
> and deletion from a sorted list is a $O(n)$ operation.  On the other
> hand, finding the <i>-th element in such a tree is also an
> $O(log(n))$ operation, while it is an $O(1)$ operation in a sorted
> list.

Granted. I don't see any way that a complex structure is ever going to
replace a simple array at the implementation level, though they might be
combined in the syntax (like lists, sets, vectors, vecFFE's and blists are
now). As a general purpose structure, however, I think the objective should
be to do almost everything in O(log n) time (and O(n) space). The change
from O(1) to O(log n) is relatively slight compared to the change from O(log
n) to O(n).

		Steve



From greil@guug.de Sat Sep  5 14:56:31 1992
From:       greil@guug.de "Toni Greil"
Date:       Sat, 5 Sep 92 14:56:31 +0200
Subject:    Gauss Numbers: how to generate them ?

I'm only a "contemplative" member of the gap-forum and I wonder, if GAP can
help to attack the following problem (to find a representation of a semigroup).
The following text I also sent to the newsgroup "sci.math".

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

Subject: Gauss Numbers: how to generate them ?


I suppose, that the following problem is already solved, perhaps in another
context. I'm not a professional researcher, but only fascinated by the question.

Background:
----------
The Modular Group acts discontinously on the hyperbolic plane, thus
creating a tesselation of this space. In the boundary of the hyperbolic
plane - for the half space model this is the completed real axis - all 
the rational numbers are created by the tessalation.

On this ground a process can be organized, which generates each positive
rational number exactly once. 
This beautiful procedure is named "Stern-Brocot tree" in
     R.L. Graham, D.E. Knuth, O. Patashnik: "Concrete Mathematics",
     Reading Mass. 1989, p.116-123, p.291-292.
and it is demonstrated there by elementary means.

The homogeneous binary tree of Stern-Brocot corresponds to the free semigroup
of rank two, where the free generators are two Moebius transformations t1, t2,
represented by the matrices

  m1:  (1  1)       m2:  (1  0)
       (0  1)            (1  1) .

Then each Moebius transformation from the generated semigroup maps the
number 1 to a different positive rational number; and each positive rational
number is obtained in this way (bijection).


Foreground:
----------
The Picard Group acts discontinously on the hyperbolic three-space, it is a
natural generalization of the Modular Group and it contains the Mod. Group.
Most works in a strong analogy: on the boundary of hyperbolic three-space
the Gauss numbers (as quotients of integer Gauss numbers) are created now
by the tessalation of the Picard Group. This analogy is discussed intensively
already in
    R. Fricke, F. Klein: "Vorlesungen ueber die Theorie der automorphen
    Funktionen", Leipzig 1897, Vol.1, p. 76-93.

Another reference is
    W. Magnus, "Noneuclidean Tesselations and Their Groups", New York 1974
    (there, on page 177, figure 18 visualizes the Stern-Brocot tree).


Problem:
-------
Is there a process, which generates each Gauss Number exactly once, in an
analogy to the Stern-Brocot tree ?  (that is: "as free as possible")

This seems to be equivalent to the question:

  Which semigroup is generated by the four Moebius transformations t1,t2,t3,t4
  (without their inverses and) represented by the matrices m1, m2, m3, m4 
  (where: "i" = imaginary unit)

    m1:  (1  1)       m2:  (1  0)      m3:  (1  i)       m4:  (1  0)
         (0  1)            (1  1)           (0  1)            (i  1)

How can this semigroup be composed, e.g. as a direct product, a free product 
with amalgamations or something else ?

There can be easily found some relations  ("13" stands for "t1*t3", etc.):
   13 = 31,  24 = 42,  143 = 432,  234 = 341,  343 = 434
   (34)**3 = (43)**3 = identity

Any hints for a solution would be welcome!

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

A further natural extension of the problem is:

  - how to generate all rational quaternions ?
  - how to generate all rational octaves (CAYLEY algebra) ?

as limit points of the hyperbolic spaces H^5 resp. H^9, created by the
reflections of the resp. regular polytope with all angles zero, corresponding
to the zero-angle tetrahedron in H^3.

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

Toni Greil, Muenchen (Germany)
greil@guug.de



From neubuese@samson.math.rwth-aachen.de Tue Sep  8 08:46:44 1992
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Tue Sep 8 08:46:44 1992
Subject:    deregistering

In a letter of Aug. 26, Simon (?) asks how to deregister from the gap-forum.
According to the announcement of GAP (section 8, p15) you have to send 
the message

   unsubscribe gap-forum 

 to

   listserv@samson.math.rwth-aachen.de

Try!

Joachim Neubueser



From aeb@win.tue.nl Tue Sep  8 12:40:07 1992
From:       aeb@win.tue.nl "A.E. Brouwer"
Date:       Tue, 8 Sep 92 12:40:07 +0200
Subject:    gap does not factorize Fermat non-primes

Script started on Tue Sep  8 12:34:24 1992
gapwsdw01:aeb% gap
                                                                      
                 ########            Lehrstuhl D fuer Mathematik      
               ###    ####           RWTH Aachen                      
              ##         ##                                           
             ##          #             #######            #########   
            ##                        #      ##          ## #     ##  
            ##           #           #       ##             #      ## 
            ####        ##           ##       #             #      ## 
             #####     ###           ##      ##             ##    ##  
               ######### #            #########             #######   
                         #                                  #         
                        ##           Version 3              #         
                       ###           Release 1              #         
                      ## #            7 Apr 92              #         
                     ##  #                                            
                    ##   #           Johannes Meier, Martin Schoenert 
                   ##    #           Alice Niemeyer, Werner Nickel    
                  ##     #           Alex Wegner,    Thomas Bischops  
                  ###   ##           Juergen Mnich,  Frank Celler     
                   ######            Thomas Breuer,  Goetz Pfeiffer   
                                     Udo Polis                        
                                                                      
                                     For help enter: ?<return>        

gap> IsPrime(274177*67280421310721);
true
gap> 
wsdw01:aeb% 

script done on Tue Sep  8 12:35:14 1992



From sl25@cus.cam.ac.uk Tue Sep  8 17:49:20 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Tue, 8 Sep 92 17:49:20 +0200
Subject:    From USENET

Article 361 of sci.math.symbolic:
Path: pavo.csi.cam.ac.uk!uknet!mcsun!uunet!spool.mu.edu!wupost!csus.edu!sfsuvax1.sfsu.edu!uwostner
From: uwostner@sfsuvax1.sfsu.edu (Ulf Wostner)
Newsgroups: sci.math.symbolic
Subject: Group theory on the Mac/Quadra
Keywords: group non-commutative algebra quadra
Message-ID: <1992Sep6.185327.7095@csus.edu>
Date: 6 Sep 92 18:53:27 GMT
Sender: news@csus.edu
Organization: San Francisco State University
Lines: 18
Originator: uwostner@sfsuvax1.sfsu.edu

I would like to use Mathematica to work with groups and would
greatly appreciate any pointers to existing work.

Alternatively, is there a version of GAP that runs on the Quadra?

Thanks,

Ulf Wostner

===
wostner@nes.nersc.gov
fax (510) 649-7830
===
- -- 
===========================================================
Ulf Wostner                   wostner@nes.nersc.gov
Math Dept, CCSF               uwostner@sfsuvax1.sfsu.edu
Voice: 510-848-2343           AppleLink: CCSF.MATH 



------------------------------ End of forwarded message 1



From neubuese@samson.math.rwth-aachen.de Wed Sep  9 10:08:15 1992
From:       neubuese@samson.math.rwth-aachen.de "Joachim Neubueser"
Date:       Wed Sep 9 10:08:15 1992
Subject:    GAP on Macintosh

Steve Linton  has  forwarded a  question  of  Ulf  Wostner  about  the
availability  of GAP on  the Quadra.  We have also been asked  several
times about the availability on other members of the Macintosh family.
I therefore want to answer in the gap-forum:

We do not have any  Macs at  Lehrstuhl D in Aachen and we also have no
easy access to such machines. Therefore in view of our restrictions in
manpower we do not plan to engulf ourselves  into a portation to these
computers.  On  the  other  hand  we  fully  realize  that  these  are
widespread  machines, perhaps even more so  in the US than in  Germany
and we would like to see GAP being  available on them.   Therefore the
public challenge if there is  somebody  who is  willing  to  do such a
port. We  would certainly  be  willing to be of any possible help with
this, in particular to provide any information or explanation  needed.
In case somebody volunteers, would (s)he please contact us or announce
this  plan in  the  gap-forum, just  in  order  to  avoid  unnecessary
duplication of work.

I would like to mention in  this context that the port to 386/486  PCs
was done by Steve Linton, so also not in Aachen, and I like to express
our thanks to him for this help.

Hoping for (many) volunteers        Joachim Neubueser



From mendel@ccu.umanitoba.ca Wed Sep  9 23:05:14 1992
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Wed, 9 Sep 92 23:05:14 +0200
Subject:    GAP on Mac

 GAP has been ported to Mac at the University of Manitoba.
It will be put on our main frame within a week from  which it 
will be obtainable using ftp anonymous.  I will send details as
soon as possible.  N. S. Mendelsohn.
i



From aeb@win.tue.nl Thu Sep 10 13:57:27 1992
From:       aeb@win.tue.nl "A.E. Brouwer"
Date:       Thu, 10 Sep 92 13:57:27 +0200
Subject:    gap does not factor Fermat non-primes

Script started on Tue Sep  8 12:34:24 1992
gapwsdw01:aeb% gap
                                                                      
                 ########            Lehrstuhl D fuer Mathematik      
               ###    ####           RWTH Aachen                      
              ##         ##                                           
             ##          #             #######            #########   
            ##                        #      ##          ## #     ##  
            ##           #           #       ##             #      ## 
            ####        ##           ##       #             #      ## 
             #####     ###           ##      ##             ##    ##  
               ######### #            #########             #######   
                         #                                  #         
                        ##           Version 3              #         
                       ###           Release 1              #         
                      ## #            7 Apr 92              #         
                     ##  #                                            
                    ##   #           Johannes Meier, Martin Schoenert 
                   ##    #           Alice Niemeyer, Werner Nickel    
                  ##     #           Alex Wegner,    Thomas Bischops  
                  ###   ##           Juergen Mnich,  Frank Celler     
                   ######            Thomas Breuer,  Goetz Pfeiffer   
                                     Udo Polis                        
                                                                      
                                     For help enter: ?<return>        

gap> IsPrime(274177*67280421310721);
true
gap> 
wsdw01:aeb% 

script done on Tue Sep  8 12:35:14 1992



From sl25@cus.cam.ac.uk Thu Sep 10 14:33:35 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Thu, 10 Sep 92 14:33:35 +0200
Subject:    Re: GAP on Macintosh 

I can't do a Mac port, as I don't have a Mac, but I would like to point
out, by way of encouragement, that the 386 port was incredibly easy,
thanks to the very high coding standards of GAP. A port to a Mac under
A/UX should be trivial, and even MacOS shouldn't be too difficult
provided you can assume enough physical memory.

		Steve



From martin@bert.math.rwth-aachen.de Thu Sep 10 15:04:42 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 10 Sep 92 15:04:42 +0200
Subject:    Re: gap does not factorize Fermat non-primes

In his e-mail message of 08-Sep-92 Andries E. Brouwer writes:

    gap> IsPrime(274177*67280421310721);
    true

This is  obviously a  bug.  Let me discuss  it a  little  bit.  Note that
274177 * 67280421310721 is 2^64 + 1.

First  note that  the  problem is not that GAP cannot  *factorize* Fermat
non-primes.  GAP's function 'Factors'  doesn't even *try* to factor  this
integer, because it believes  it is a  prime.  That is  to  say  that the
problem is in  'IsPrime' not in  'Factors'.   If 'IsPrime' is changed  so
that it  returns the correct answer, 'Factors' has  no problems at all to
split this integer.

Now  let me  describe how 'IsPrime(  N )' works.  First it checks  that N
does  not have any prime factors less than 1000.  2^64+1 obviously passes
this test.

Next 'IsPrime' tests whether N is a (strong) pseudoprime to base 2.  That
is, 'IsPrime' tests whether  2^(N-1) = 1 mod  N.   In  this case we  have
2^128 = 1 mod (2^64+1), so 2^64+1 passes this test too.

Finally 'IsPrime' performs another similar test, however this  time using
GF(N^2),  instead  of  GF(N)  as above.  To do  this  'IsPrime' selects a
polynomial X^2 - P X + 1, and works in (Z_N)[X]/(X^2 - P X + 1).  If N is
a prime and X^2 - P  X  + 1 is irreducible,  this is the  field  with N^2
elements.  The multiplicative group of this field has order N^2-1, so any
element of this field has an order that divides N^2-1.  So 'IsPrime' test
whether X^(N^2-1) is trivial in the ring (Z_N)[X]/(X^2  - P X + 1).   The
hope is  of  course that  X  will have an order that is not  a divisor of
N^2-1 if N is not a prime.

Now I have to say how X^2 - P X + 1, i.e.,  the parameter P, is selected.
'IsPrime' takes the smallest  P such that Jacobi( P^2-4,  N ) = -1.  If N
is a  prime  this  implies  that X^2 - P X +  1 is  irreducible modulo N.
Because Jacobi( -3, 2^64+1  )  =  -1, 'IsPrime' takes P = 1 in this case.
But X^2 - X + 1 is the sixth cylotomic polynomial, thus the element X has
order  6 in Z[X]/(X^2 - X  + 1), and  thus an  order dividing  6  in  any
(Z_N)[X]/(X^2 - X + 1).  So the whole test  comes down to testing whether
6 divides N^2-1, which is equivalent to gcd( N, 6 ) = 1.

The corresponding problem for the  (strong) pseudoprime test would  be to
test if N is  a (strong) pseudoprime w.r.t. the base -1.

The fix  is very simple  of  course.   Instead  of  selecting  the  first
positive p such that Jacobi( p, N ) = -1, 'IsPrime' should take the first
such p that is greater than 1.

If somebody wants to fix the problem right away, here is the necessary
change.

--- integer.g	1992/03/19 18:16:39
+++ integer.g	1992/09/10 12:38:07
@@ -344,7 +347,7 @@
     fi;
 
     # find a quadratic nonresidue $d = p^2/4-1$ mod $n$
-    p := 1;  while Jacobi( p^2-4, n ) <> -1  do p := p+1;  od;
+    p := 2;  while Jacobi( p^2-4, n ) <> -1  do p := p+1;  od;
 
     # for a prime $n$ the trace of $(p/2+\sqrt{d})^n$ must be $p$
     # and the trace of $(p/2+\sqrt{d})^{n+1}$ must be 2

Martin.

PS: Now  comes the strange part.  When I wrote 'IsPrimeInt' I knew  about
this problem, that certain  polynomial would lead to very weak tests, and
should  be avoided.   How could  I fail to see that x^2 - x + 1 is such a
polynomial?   Well this is more than 2 years ago, so my  memory  is a bit
hazy.  Still it leaves me puzzled.

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



From martin@bert.math.rwth-aachen.de Thu Sep 10 15:21:21 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 10 Sep 92 15:21:21 +0200
Subject:    Re: gap does not factor Fermat non-primes

In his e-mail message  of 10-Sep-92 Andries  Brouwer  complains a  second
time  about the  fact that GAP  is  unable  to  factor Fermat non-primes.
Assuming that he isn't extremly impatient, I suppose this  is because  he
did not see his  own message in  the GAP forum and feared that it did not
get through.  This  is actually the default, the  originator of a message
does  not receive a copy from the GAP forum.  To change this  default one
can mail a request to

    listserv@samson.math.rwth-aachen.de

with a line containing the command

    set gap-forum mail ack

Martin.

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



From werner@pell.anu.edu.au Thu Sep 10 15:25:17 1992
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Thu, 10 Sep 92 15:25:17 +0200
Subject:    Re: gap does not factorize Fermat non-primes

Martin Schoenert wrote:

   PS: Now  comes the strange part.  When I wrote 'IsPrimeInt' I knew  about
   this problem, that certain  polynomial would lead to very weak tests, and
   should  be avoided.   How could  I fail to see that x^2 - x + 1 is such a
   polynomial?   Well this is more than 2 years ago, so my  memory  is a bit
   hazy.  Still it leaves me puzzled.
   
We all have our weak moments.  Don't worry too much.

Werner Nickel
Mathematics Research Section
Australian National University



From akgul@trbilun.bitnet Thu Sep 10 16:15:25 1992
From:       akgul@trbilun.bitnet "Mustafa Akgul"
Date:       Thu, 10 Sep 92 16:15:25 +0200
Subject:    Re: GAP on Macintosh

Where can I find gap386.exe ?

thanks



From martin@bert.math.rwth-aachen.de Thu Sep 10 16:20:01 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Thu, 10 Sep 92 16:20:01 +0200
Subject:    Re: Re: GAP on Macintosh

Via 'ftp'  on  'samson.math.rwth-aachen.de'.   I  don't  think  the other
servers have this file.

Martin.

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



From boris@mathematik.uni-bielefeld.de Fri Sep 11 11:36:54 1992
From:       boris@mathematik.uni-bielefeld.de "Boris Hemkemeier"
Date:       Fri, 11 Sep 92 11:36:54 +0200
Subject:    Gap mirror (was: Re: GAP on Macintosh)

> 
> Via 'ftp'  on  'samson.math.rwth-aachen.de'.   I  don't  think  the other
> servers have this file.

ftp.mathematik.uni-bielefeld.de:/pub/math/gap is a enhanced
(actual gap manual in PostScript) and actual mirror of
samson.math.rwth-aachen.de:/pub/gap .

Other (*free*) computer algebra packages are welcome. Please send mail
to boris@mathematik.uni-bielefeld.de. or
ftpmaster@ftp.mathematik.uni-bielefeld.de. 

ftp.mathematik.uni-bielefeld.de has a satisfying Internet connectivity
(no WIN-traffic in germany for *.edu and *.au connections).
-- 
			  "Say no to bugs!"
Boris Hemkemeier	boris@mathematik.uni-bielefeld.de.


From mendel@ccu.umanitoba.ca Tue Sep 22 16:18:49 1992
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Tue, 22 Sep 92 16:18:49 +0200
Subject:    GAP on Mac

The Mac version of GAP can now be obtained by ftp ccu.umanitoba.ca in the
directory /pub/mac/GAP.sit.hqx  When extracted it will contain everything
except that the folder doc will be empty.  Since the doc files are text
files they may be obtained from many sources. They can then be put in the
doc folder.  If any problems arise please let me know.  The porting of GAP
to Mac was carried out by Prof. Harry Lakser.
N. S. Mendelsohn



From mendel@ccu.umanitoba.ca Tue Sep 22 18:14:34 1992
From:       mendel@ccu.umanitoba.ca "N. S. Mendelsohn"
Date:       Tue, 22 Sep 92 18:14:34 +0200
Subject:    GAP to Mac

This is a repetition of a previous message since it appears that the
original was not sent.  The Mac version of GAP may now be obtained using
 ftp ccu.umanitoba.ca in the directory /pub/mac/GAP.sit.hqx The only
changes made were the inclusion of a readme file. When unpacked there will
be included
an empty doc folder.  The doc files are text files which may be obtained
from 
many sources.  These should be put in the doc folder.  The porting to Mac
was carried out by Prof. Harry Lakser.  His comments appear in the readme
file. 
N. S. Mendelsohn



From martin@bert.math.rwth-aachen.de Mon Sep 28 17:57:09 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 28 Sep 92 17:57:09 +0100
Subject:    Re: homorphisms from fp groups

There  were two e-mails to the GAP  Forum that I wanted to answer  for  a
very long  time.   I apologize that it took me so long.  I hope that this
is still interesting.

In his e-mail of 8-Jun-92 David Sibley wrote:

    Again I am a bit confused and would appreciate some pointers on how best
    to do the following.

    Note: I have not yet done either of the upgrades and that might be my
    problem.  We  are going to install Gap in a different place and I am
    waiting on the upgrade until we move it.

Well  neither the first nor the second upgrade would have been  any help.
However, the third  upgrade, which I  sent  out together with this answer
will help.   I will  first discuss  how to  solve  your problem  and then
afterwards give some hints why this did not work in GAP 3.1 patchlevel 2.

David continues:

    I have a finitely presented group (it's M11) and a subgroup.  I use
    OperationCosetsFpGroup to get the permutation representation on the
    cosets of the subgroup.

    1.  OperationHomomorphism does not produce the homomorphism I want.
    I just get an error message that the permutation group is the wrong
    kind of thing.  Why doesn't this work?  (Even if it's not designed to,
    I think it should, just so one can do what I'm trying to do here.)

Well here is an example of what can be done in GAP 3.1 patchlevel 3.

    gap> # first define m11 as a finitely presented group
    gap> a := AbstractGenerator( "a" );
    gap> b := AbstractGenerator( "b" );
    gap> c := AbstractGenerator( "c" );
    gap> m11 := Group( a, b, c );;
    gap> m11.relators := [ a^11, b^5, c^4, (a*c)^3, a^b/a^4, b^c/b^2 ];;
    gap> m11.name := "m11";;
    gap>
    gap> # take the subgroup of index 12 and the operation on its cosets
    gap> m11_12 := Subgroup( m11, [ a^3, b, c^2 ] );
    gap> m11_p := OperationCosetsFpGroup( m11, m11_12 );
    Group( ( 2, 3, 4, 7, 5, 9,10,11, 8,12, 6),
           ( 3, 5, 9,12, 7)( 4, 8, 6,11,10), 
           ( 1, 2)( 3, 6,12,11)( 4, 7)( 5,10, 9, 8) )
    gap>  m11_p.name := "m11_p";;
    gap>
    gap> # make the homomorphism from m11 into the permutation group
    gap> h := OperationHomomorphism( m11, m11_p );
    GroupHomomorphismByImages( m11, m11_p,
                           [ a, b, c ], 
                           [ ( 2, 3, 4, 7, 5, 9,10,11, 8,12, 6),
                             ( 3, 5, 9,12, 7)( 4, 8, 6,11,10), 
                             ( 1, 2)( 3, 6,12,11)( 4, 7)( 5,10, 9, 8) ] )
    gap>
    gap> # compute the 2-Sylow subgroup in the permutation group
    gap> SylowSubgroup( m11_p, 2 );
    Subgroup( m11_p,
          [ ( 2,10)( 4,12)( 5, 9)( 6, 7),
            ( 3, 8)( 4,12)( 5, 7)( 6, 9), 
            ( 1,11)( 2, 4)( 6, 7)(10,12),
            ( 1, 3)( 2, 6,10, 7)( 4, 5,12, 9)( 8,11) ] )
    gap>
    gap> # and pull the result back to m11
    gap> List( last.generators, gen -> PreImagesRepresentative( h, gen ) );
    [ b^-4*a^-2*c^-2*a^-1*b^-2*a^-7,
      a^-2*c^-2*a^-1*b^-1*a^-6, 
      b^-2*c^-2*b^-1*a^-2*c^-2*a^-1*b^-1*a^-2
     *c^-2*a^-1*b^-1*c^-1*a^-2*b^-1*c^-1, 
      b^-2*c^-2*b^-3*a^-8*c^-1*a^-1*b^-1*a^-1 ]
    gap> Index( m11, Subgroup( m11, last ) );
    495

You  probably noticed that I did not simply computed the  2-Sylowsubgroup
of the finitely presented group with  'PreImage(SylowSubgroup(m11_p,2))'.
There is a reason for that, which I want to formulate as a warning.

    You should *not* use  'PreImage',  'PreImages', or  'Kernel'  for  an
    operation  homomorphism (build  by  'OperationHomomorphism')  from  a
    finitely presented group onto the group given by the operation on the
    cosets  of a subgroup  (as build by 'OperationCosetsFpGroup') in  any
    but the smallest examples.

The reason is that in  those cases  it is necessary to compute the kernel
of the homomorphism.   And  I don't  know a  way to  compute  this kernel
without writing down the coset table of this kernel (in fact I don't even
know a  way to test  whether this kernel is trivial without  writing down
the coset table  of this kernel).  Because the index of the kernel in the
whole group is likely to be rather large this will take a lot of time and
probably a lot of space (if it works at all  in  any reasonable amount of
time and memory).

David continues:

    2.  I use GroupHomomorphismByImages to produce the homomorphism I want
    anyway.  As recommended, I set the field isMapping to true.  I then
    try to compute an image: Image(f,a).  Since a is one of the original
    abstract generators, this should be trivial and instantaneous.  It's
    not.  After waiting a bit, I abort this operation and use
    ImagesRepresentative instead.  This gives an immediate answer. Why
    is Image not working here?

This will also  now  work in GAP  3.1  patchlevel 3.  However  in GAP 3.1
patchlevel  2  this  is  what  happened.   'GroupHomorphismByImages'  was
implemented using the generic functions  that should work for all groups.
When asked to compute the image of an element under such an homomorphism,
'Image'   (actually   'GroupHomomorphismByImagesOps.Image')   makes   two
parallel lists.  One  contains all  the elements  of  the source, and the
other list contains the image of the corresponding element in the source.
This is done by generating all elements of  the source using a orbit like
algorithm and performing exactly the same computations with the images of
the  generators.   Now  for  finitely presented  groups  the  process  of
enumerating all elements of the source  will actually never stop, because
instead  of really  enumerating  the elements of the source,  the process
will try to enumerate the elements of the coressponding free group.  This
will fail  of  course.  But if you  interrupt the  computation after some
time, quite a  bit of elements  and  there images will already  be found.
This  partial list will already be stored in the homomorphism record.  If
you  now call 'ImagesRepresentative' (the same thing would  happen if you
simply  called 'Image' again),  'ImagesRepresentative' thinks that  those
lists are complete, will look  up 'a' in the list  of  elements, find  it
there, and return the corresponding element in the images list.

David continues:

    Generally, I would think that for efficient computations one wants to
    use some small-degree permutation represenation of the group.  Yet one
    also must keep some connection to the original presentation of the
    group in most cases.  This is all I'm trying to do here.  If there's a
    better way, or this is the wrong idea, please let me know.

Of course, what you say is absolutely correct.

In his e-mail message of 19-Jun-92 Allan Adler addresses the same issue:

    I'm glad to see the recent articles on going from a finitely presented
    group to a permutation group in GAP. I have been having trouble with
    just this. I would find it helpful if someone would post a complete
    example of how this is done. Specifically:

    Let's say I define G as a finitely presented group and H as a subgroup:

    a:=AbstractGenerator("a");
    b:=AbstractGenerator("b");

    G:=Group(a,b);
    G.relators:=[a^2,b^3,(a*b)^5]

    H:=Subgroup(G,[a,(b*a)^2*b^-1];

    OperationCosetsFpGroup(G,H);

    So far, I am following the example of 21.5 of the GAP manual. According
    to that example, GAP now returns:

    Group( (2,3)(4,5), (1,2,4) );

    Can someone now post the code that (with this example) lets one take
    any word w in a,b and returns the corresponding permutation, along with
    a transcript showing that the code works?

This answer is again that  this will only work in  GAP 3.1  patchlevel 3.
There however  it  is very  easy.  Assuming the  name of  the permutation
group is 'P' then you just enter

    hom := OperationHomomorphism( G, P );
    Image( hom, a*b*a );

to get

    (1,3,5)

Hope this helps.  Again I apologize that this took so long.

Martin.

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



From martin@bert.math.rwth-aachen.de Mon Sep 28 18:14:23 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Mon, 28 Sep 92 18:14:23 +0100
Subject:    Upgrade for GAP 3.1 patchlevel 2 (V3R1P2) to patchlevel 3 (V3R1P3)

This file  contains the 'uuencode'-d 'compress'-ed upgrade  file  for the
third  upgrade  for GAP 3.1.   This  upgrade  brings version 3 release  1
patchlevel 2 (V3R1P2)  to version 3 release 1 patchlevel 3 (V3R1P3).  The
priority of this upgrade is medium.

To apply  this upgrade  you must first  apply  the  first and the  second
upgrade.   You  can  obtain  these  upgarde  via   anonymous  'ftp'  from
'samson.rwth-aachen.de'.  If you  have already applied those upgrades you
need not (actually must not) apply it again.

Save this mail as a  file with  name 'upg3r1p3.uue',  unpack  the upgrade
file with 'uudecode upg3r1p3.uue' (or 'uud upg3r1p3.uue') and 'uncompress
upg3r1p3.dif.Z'.   Then read the beginning of  the unpacked  upgrade file
'upg3r1p3.dif', which contains instructions how to apply this upgrade.

[removed the upgrade, it is available as 'upg3r1p3.dif.Z'  from the 'ftp'
server 'samson.math.rwth-aachen.de']


From werner@pell.anu.edu.au Tue Sep 29 00:45:08 1992
From:       werner@pell.anu.edu.au "Werner Nickel"
Date:       Tue, 29 Sep 92 00:45:08 +0100
Subject:    patch level 3

Why does the upgrade to patch level 3 not fix known bugs in the
GAP kernel ?

Werner Nickel
Mathematics Research Section
Australian National University


From sl25@cus.cam.ac.uk Tue Sep 29 08:25:03 1992
From:       sl25@cus.cam.ac.uk "S. Linton"
Date:       Tue, 29 Sep 92 08:25:03 +0100
Subject:    Re: Upgrade for GAP 3.1 patchlevel 2 (V3R1P2) to patchlevel 3 (V3R1P3) 

I am afraid that there will be a delay in the delivery of the 386
executable of V3R1P3, as I will be away from my PC until roughly
Christmas.

Sorry
		Steve


From martin@bert.math.rwth-aachen.de Tue Sep 29 12:00:07 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 29 Sep 92 12:00:07 +0100
Subject:    Re: patch level 3

In his e-mail message of 29-Sep-92 Werner Nickel wrote

    Why does the upgrade to patch level 3 not fix known bugs in the
    GAP kernel ?

We hope to have GAP 3.2 out really  soon now ;-) It's kernel will fix all
known  bugs.  BTW, which  bugs are  you referring  to?   The  only really
serious bug that I know of is the one  in  'IsMatrix'.  Are you  aware of
other serious problems?

Martin

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


From dentzer@kalliope.iwr.uni-heidelberg.de Tue Sep 29 12:13:16 1992
From:       dentzer@kalliope.iwr.uni-heidelberg.de "Ralf Dentzer"
Date:       Tue, 29 Sep 92 12:13:16 +0100
Subject:    About GAP

Hello!

When I read the very good introductory chapter "About GAP" of the GAP manual,
some minor comments/questions came to my mind.

1) The contrary of "Intersection" is in many Categories not the "Union",
	but the smallest object (domain), containing the given ones.
	Such a function, maybe called "Compositum", would make more sense
	than "Union".

2) Why are there no Iterators, generating all elements of a domain
	exactly once, but without putting them all into a list.
	This is easy to achieve for e.g. permutation groups,
	and useful in various places. There could also be a
	construct like "for a in D do" where D is a domain, and an
	iterator is used to generate the a.
	(Similar to  "for i in [1..6] do")

3) It seems to me that the definition of "<" in the ResidueClass
	example in 1.28 leads to problems if you want to define two
	new types of group elements independently and to compare
	two of those. The problems arise if you want to put them
	into a sorted list (a set).

I must admit that I could implement the proposals 1) and 2) (partially) for
myself, if I really needed them. Maybe the designers of GAP have
thought about these things and have their reasons for not doing them.
But if this is not case they are certainly better in doing a proper
implementation and defining a good standard for these things.


Greetings

	Ralf Dentzer



From martin@bert.math.rwth-aachen.de Tue Sep 29 12:18:03 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 29 Sep 92 12:18:03 +0100
Subject:    Re: Re: Upgrade for GAP 3.1 patchlevel 2 (V3R1P2) to patchlevel 3 (V3R1P3) 

As Werner noted in his e-mail there are no changes  in the kernel between
GAP  V3R1P2  and  V3R1P3.   So  there  should be no reason to make  a new
executable for  the  386, unless you have a  new  version of DJGPP  which
fixes the problem with <ctr>-'C'.

Martin.

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



From obrien@pell.anu.edu.au Tue Sep 29 12:46:35 1992
From:       obrien@pell.anu.edu.au "Eamonn O'Brien"
Date:       Tue, 29 Sep 92 12:46:35 +0100
Subject:    permutation gp degrees

If one has defined a permutation group in GAP, 
is there a *sensible* way to obtain the degree 
of this group? 

Thanks for any advice.

Eamonn O'Brien
Australian National University



From martin@bert.math.rwth-aachen.de Tue Sep 29 12:50:20 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 29 Sep 92 12:50:20 +0100
Subject:    Re: About GAP

In his e-mail message of 29-Sep-92 Ralf Dentzer wrote:

    When I read the very good introductory chapter "About GAP" of the GAP
    manual, some minor comments/questions came to my mind.

    1)  The contrary of "Intersection" is in many Categories not the "Union",
	but the smallest object (domain), containing the given ones.
	Such a function, maybe called "Compositum", would make more sense
	than "Union".

We call it 'Closure'.  Actually we only make it available  for groups and
there subgroups.  Is  it really necessary  to  have  this  for the  other
categories  as well?  If so  I would suggest  using 'Closure'  instead of
'Compositum'.  Opinions anyone?

He continues:

    2)  Why are there no Iterators, generating all elements of a domain
	exactly once, but without putting them all into a list.
	This is easy to achieve for e.g. permutation groups,
	and useful in various places. There could also be a
	construct like "for a in D do" where D is a domain, and an
	iterator is used to generate the a.
	(Similar to  "for i in [1..6] do")

We have plans to allow this.  So that you can write

    for <var>  in <domain>  do
        <statements>
    od;

This is a  little bit  difficult, because it  should be  possible to loop
over one  domain several times in parallel.  I.e., it should be  possible
to say

    for g  in D12  do
        for h  in D12  do
            <do something with the pair g, h>
        od;
    od;

He continues:

    3)  It seems to me that the definition of "<" in the ResidueClass
	example in 1.28 leads to problems if you want to define two
	new types of group elements independently and to compare
	two of those. The problems arise if you want to put them
	into a sorted list (a set).

Yes this  is  true.  We  simply  don't know  a good  concept  which would
guarantee a well ordering for all types of group elements, ring elements,
domains,  etc. that one might want to define.  So we (Frank Celler and I)
agreed that we simply  would wait until somebody has  a  problem with it.
Our idea was that if nobody ever has a problem  with it  (because  nobody
ever tries to make a set  with group elements  of different  types), then
all the effort spent to  come  up with a  concept would be wasted. And we
simply hate to waste effort.

He continues:

    I must admit that I could implement the proposals 1) and 2) (partially)
    for myself, if I really needed them.  Maybe the designers of GAP have
    thought about these things and have their reasons for not doing them.
    But if this is not case they are certainly better in doing a proper
    implementation and defining a good standard for these things.

As I already remarked, we have  no reasons for not doing proposals 1) and
2), but they are  not very  high on our priority list.  If someone really
needs them, tell me, that will push them closer to the top.

Martin.

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




From martin@bert.math.rwth-aachen.de Tue Sep 29 12:55:47 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Tue, 29 Sep 92 12:55:47 +0100
Subject:    Re: permutation gp degrees

In his e-mail of 29-Sep-92 Eamonn O'Brien asks

    If one has defined a permutation group in GAP, 
    is there a *sensible* way to obtain the degree 
    of this group? 

There are two functions that are related to this.

One is  'PermGroupOps.LargestMovedPoint', which takes a permutation group
and returns the largest moved point.   This what was called the degree of
a permutation group in GAP 2.4.

The  other function is  'DegreeOperation', which  returns the  number  of
points moved by a group.

For an example take this definition

    gap> a5 := Group( (1,3,4), (1,3,4,5,6) );;
    gap> PermGroupOps.LargestMovedPoint( a5 );
    6
    gap> DegreeOperation( a5, [1..PermGroupOps.LargestMovedPoint(a5)] );
    5

Martin.

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



From geoff@math.ucla.edu Tue Sep 29 23:46:49 1992
From:       geoff@math.ucla.edu "Geoffrey Mess"
Date:       Tue, 29 Sep 92 23:46:49 +0100
Subject:    patch on NeXT

Using patch-2.0.12u3, I tried to do the first upgrade.  I got the  
following results:

argo.math.ucla.edu> patch -p0 < upg3r1p1.dif
Hmm...  Looks like a unified diff to me...
The text leading up to this was:

[... about 200 lines of text ...]

|Now for the upgrade itself
|==========================
|
|diff -u doc/aboutgap.tex doc/aboutgap.tex
|--- doc/aboutgap.tex   Thu Apr  9 14:06:31 1992
|+++ doc/aboutgap.tex   Thu Apr 30 14:38:06 1992
--------------------------
File to patch: ^C
[ I exited with control C ]
I tried again using -pO instead of -p0 (literal rather than numeral)  
and got the same result. This doesn't agree with the statement in the  
upgrade that 


  Versions  of  'patch'  before  2.0.2.0  (patchlevel  12u4)   don't
|    understand the unified 'diff' format of this upgrade file.   In  
this case
|    you will see the following message.
|
|      Hmm...  I can't seem to find a patch in there anywhere.
|


I tried to install patch-2.0.12u4 (obtained from samson), but the  
Configure process exited unsuccessfully. Has anyone succeeded either  
in installing patch-2.0.12u4 on a Next or in doing the upgrade with  
patch-2.0.12u3 ?

Geoffrey Mess


From martin@bert.math.rwth-aachen.de Wed Sep 30 09:16:37 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 30 Sep 92 09:16:37 +0100
Subject:    Re: patch on NeXT

Geoffrey Mess writes in his e-mail message of 29-Sep-92:

    Using patch-2.0.12u3, I tried to do the first upgrade.  I got the  
    following results:

    argo.math.ucla.edu> patch -p0 < upg3r1p1.dif
    Hmm...  Looks like a unified diff to me...
    The text leading up to this was:

    [... about 200 lines of text ...]

    |Now for the upgrade itself
    |==========================
    |
    |diff -u doc/aboutgap.tex doc/aboutgap.tex
    |--- doc/aboutgap.tex   Thu Apr  9 14:06:31 1992
    |+++ doc/aboutgap.tex   Thu Apr 30 14:38:06 1992
    --------------------------
    File to patch: ^C

I just  checked.   Unified  diff  format support  was added to 'patch' in
version 12u1 and the ability  to recognize it automatically  was added in
version 12u2.  Thus your version 12u3 should have no  problems  with  it.
In  fact  'patch's  output  'Hmm...   Looks like a unified diff to me...'
shows that it recognizes the format correctly.

Instead the  problem seems to be something else.  For some reason 'patch'
cannot  find  the file  'doc/aboutgap.tex'.   The  argument  '-p0'  tells
'patch' to take the filenames exactely as they  are, without it  it would
look  for 'aboutgap.tex' in  the  current directory.  There  are  several
possibilities why this might happen.

The  first possibility is that you are not  in the <gap-directory>, which
is the one  with the  subdirectories 'doc/', 'lib/', and 'src/'.  In this
case you should first 'cd' to this directory before calling 'patch'.

The second possibility is that you  don't have the documentation on-line.
In this case you should simply hit <return> when 'patch'  asks  you which
file to modify.

Geoffrey Mess continues:

    I tried to install patch-2.0.12u4 (obtained from samson), but the  
    Configure process exited unsuccessfully. Has anyone succeeded either  
    in installing patch-2.0.12u4 on a Next or in doing the upgrade with  
    patch-2.0.12u3 ?

I have no idea why 'patch's  configure script should fail.  I think Frank
Celler has the version 'patch' from 'samson' installed on  his NeXT but I
cannot check this before  he returns  from his  holidays.  However,  as I
pointed out already, there should be no important difference between 12u3
and 12u4.

Martin.

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



From akgul@trbilun.bitnet Wed Sep 30 10:36:04 1992
From:       akgul@trbilun.bitnet "Mustafa Akgul"
Date:       Wed, 30 Sep 92 10:36:04 +0100
Subject:    Re: patch on NeXT

I just want to remind that patch is level 8 and there aretwo versions now:
u8 which uses Larry Wall's interactive configure and g8 uses
non-interactive gnu configure. g8 also supports long name options;
otherwise they are identical.

What about trying patch-2.0g8  from ftp.eu.net in gnu directory.
GNU version will configure itself easily.

You can also obtain patch from bilserv@trbilun.bitnet
via commands
BEGIN
REPLY full-address
INDEX patch
send patch
HELP
END


Reagrds


From geoff@math.ucla.edu Wed Sep 30 11:27:37 1992
From:       geoff@math.ucla.edu "Geoffrey Mess"
Date:       Wed, 30 Sep 92 11:27:37 +0100
Subject:    Re: patch on NeXT

Thanks; I've now used patch-2.0.12u3 successfully; the trouble was  
simply that in the doc directory I had a single file  docr1.dvi and  
had thrown away the tex files for the individual chapters. As I'm  
using gapexe.next, I told patch to skip the changes on the source  
code. 

   Is the source code for gapexe.next available ? It would seem that  
to patch the source, one would need to do apply the upgrades to the  
source code src3r1 and then make whatever changes were made in order  
to produce the source code for gapexe.next, and then recompile. (Wish  
I'd thought of that earlier :). Perhaps the simplest thing is to wait  
for Gap 3.2 ? 


Geoff Mess


From martin@bert.math.rwth-aachen.de Wed Sep 30 14:00:49 1992
From:       martin@bert.math.rwth-aachen.de "Martin Schoenert"
Date:       Wed, 30 Sep 92 14:00:49 +0100
Subject:    Re: Re: patch on NeXT

Geoffrey Mess write in his e-mail message of 30-Sep-92:

    Thanks; I've now used patch-2.0.12u3 successfully; the trouble was  
    simply that in the doc directory I had a single file  docr1.dvi and  
    had thrown away the tex files for the individual chapters. As I'm  
    using gapexe.next, I told patch to skip the changes on the source  
    code.

Good.

He continues:

   Is the source code for gapexe.next available ?

No.

He continues:

    It would seem that  
    to patch the source, one would need to do apply the upgrades to the  
    source code src3r1 and then make whatever changes were made in order  
    to produce the source code for gapexe.next, and then recompile.

Yes.

He continues:

     Perhaps the simplest thing is to wait for Gap 3.2 ? 

Yes.

Martin.

PS.  There aren't that many important changes in the kernel anyhow.  Most
changes to the kernel were  made to make it possible to compile it on the
RS/6000 and with GNU CC, and those  are clearly  unimportant to you.  The
important upgrades are in the library.

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



