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 ' or 'mailx -f '. 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: must evaluate to a list at for 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: must evaluate to a list at DS> for 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: 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( )' '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 nestings. If is positive the *expressions* of the arguments of the functions calls are printed, otherwise the *values* of the actual arguments are printed instead. 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 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 '/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 '/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 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: 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 *-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( )', which would return the *set* of key values. For an arbitrary *list* 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
writing 'Sublist(
,Keys(
))' (or '{ Keys( ) }') 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 -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 '' (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 -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: ? 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: ? 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 -'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 in do 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 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 , 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 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