This file contains the mails sent to the GAP forum in Januar-March 1993. Name Email address Mails Lines Martin Schoenert martin@bert.math.rwth-aachen.de 28 1376 Frank Celler fceller@bert.math.rwth-aachen.de 17 1294 Joachim Neubueser neubuese@samson.math.rwth-aachen.de 17 578 Steve Linton sl25@cus.cam.ac.uk 11 199 David Sibley sibley@math.psu.edu 10 169 Harald Boegeholz hwb@machnix.mathematik.uni-stuttgart.de 9 295 Jacob Hirbawi jcbhrb@cerf.net 7 288 Ralf Dentzer dentzer@polyhymnia.iwr.uni-heidelberg.de 7 204 Alexander Hulpke ahulpke@bert.math.rwth-aachen.de 6 251 Thomas Breuer sam@ernie.math.rwth-aachen.de 5 521 Jean Michel michel@dmi.ens.fr 5 249 Ansgar Kaup kaup@ccucvx.unican.es 5 58 Arnaldo Mandel am@ime.usp.br 4 126 John R. Neil neil@dehn.mth.pdx.edu 4 92 Werner Nickel werner@pell.anu.edu.au 3 95 Mark Short short@jordan.csu.murdoch.edu.au 3 77 Leonard Soicher L.H.Soicher@qmw.ac.uk 3 39 N. S. Mendelsohn mendel@ccu.umanitoba.ca 3 24 Dana-Picard Noah dana@bimacs.cs.biu.ac.il 3 22 Dr D. L. Johnson dlj@maths.nott.ac.uk 3 15 Eamonn O'Brien obrien@pell.anu.edu.au 2 83 Bruce Kaskel kaskel@math.berkeley.edu 2 77 Andrea Caranti caranti@volterra.cineca.it 2 72 Peter Mueller muellpe@mi.uni-erlangen.de 2 47 Lee Schumacher schumach@math.wisc.edu 2 36 Derek Holt dfh@maths.warwick.ac.uk 2 35 Ulderico Dardano DARDANO@matna.na.infn.it 2 33 Borcic Boris borbor@divsun.unige.ch 2 24 Volkmar Felsch felsch@samson.math.rwth-aachen.de 1 137 Ronald Biggers rbiggers@kscsuna1.kennesaw.edu 1 48 Jane Bamblett bamblett@maths.ox.ac.uk 1 38 Frederick Ford ffor@gauss.math.rochester.edu 1 34 Werenfried Spit SPIT@vm.ci.uv.es 1 33 Peter Webb webb@s5.math.umn.edu 1 31 Oliver Bonten oli@ernie.math.rwth-aachen.de 1 27 Martin Wursthorn pluto@mibtt1.mathematik.uni-stuttgart.de 1 23 Edward Spitznagel C31801ST@wuvmd.wustl.edu 1 21 Michael Smith smith@pell.anu.edu.au 1 20 Ted Hurley MATHURLEY@bodkin.ucg.ie 1 18 Keith Dennis dennis@math.cornell.edu 1 18 Lee Hawkins leh@aberystwyth.ac.uk 1 15 Meinolf Geck geck@dmi.ens.fr 1 14 Anton Greil greil@guug.de 1 14 Donald White white@mcs.kent.edu 1 13 Dawn Endico dawn@math.wayne.edu 1 10 Geoff Smith gcs@maths.bath.ac.uk 1 9 Francois Digne digne@dmi.ens.fr 1 5 Karl Brodowsky bro@clio.iwr.uni-heidelberg.de 1 3 This file is in Berkeley mail drop format, which means you can read this file with 'mail -f ' or 'mailx -f '. It is also possible however to read this file with any text editor. From neubuese@samson.math.rwth-aachen.de Mon Jan 4 13:27:50 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Mon, 4 Jan 93 13:27:50 +0100 Subject: Unsolved Problems in Group Theory (Kourovka Notebook) (fwd) In a recent letter to the GAP-forum, I mentioned the Kourovka Notebook. I got the appended detailed information about it from Dr. Khukhro who is presenly in Freiburg, Germany, which hereby I want to make known to all members of the forum. Happy New Year Joachim Neubueser ======================================================================== Forwarded message: > From khukhro@sun8.ruf.uni-freiburg.de Thu Dec 31 14:13:47 1992 > Subject: Unsolved Problems in Group Theory (Kourovka Notebook) (fwd) > To: neubuese@samson. > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Now in English! > UNSOLVED PROBLEMS IN GROUP THEORY > THE KOUROVKA NOTEBOOK > ----------------------------------------------------------------------- > The 12-th revised and augmented edition > V.D.Mazurov and E.I.Khukhro, Editors > Institute of Mathematics, Novosibirsk, 1992 > 154 p. in A5 format, softcover, 20,- DM > ----------------------------------------------------------------------- > This collection of unsolved problems in Group Theory and close areas > is published regularly, every 2-3 years, starting from 1965. Each new > edition is supplemented with new problems and brief comments on the > solved problems from the previous editions. > The problems are proposed by the experts in Group Theory and close > areas, their level varies from a Ph.D. thesis to long-standing > well-known problems. > Among the authors there are many prominent Russian mathematicians, such > as S.I.Adian, S.N.Chernikov, Yu.L.Ershov, Yu.M.Gorchakov, R.I.Grigorchuk, > M.I.Kargapolov, A.I.Kostrikin, A.I.Mal'cev, Yu.I.Merzliakov, > A.Yu.Ol'shanskii, V.P.Platonov, B.I.Plotkin, V.N.Remeslennikov, > L.A.Shemetkov, A.L.Shmel'kin, V.P.Shunkov, A.E.Zalesskii and others. > Having acquired internation popularity, the Kourovka Notebook contains > also problems of R.Baer, G.Baumslag, R.Carter, J.Dixon, R.Griess, > K.Gruenberg, B.Hartley, H.Heineken, G.Glauberman, O.Kegel, > B.Neumann, P.Neumann, R.Phillips, C.Praeger, D.Robinson, K.Roggenkamp, > J.Roseblade, J.Thompson, G.Wall, B.Wehrfritz, J.Wiegold, H.Wielandt, > J.Wilson, H.Zieschang and others. > Some of the problems are quickly solved due to the fact that they are > read by specialists from other fields of Group Theory, others wait for > substantial breakthroughs for many years. (Of course, it is often easier > to pose two problems than to solve one.) It is interesting to follow the > progress in the development of Group Theory, as more and more of these > problems become solved (for example, now about 3/4 of the problems from > the 1-st edition have been solved!). > The present book is the 12-th revised and augmented edition (1992), it > is now published in two versions, in Russian and in English. The English > version is now available for 20,- DM per copy. (This is to cover expenses > and to improve further editions; since there are now difficulties for > Russian mathematicians, this kind of support is vital for the further > existence of the Kourovka Notebook.) > Orders (a check, 20,- DM per copy, may be enclosed) > should be sent to > > E.I.Khukhro (e-mail: khukhro@sun1.ruf.uni-freiburg.de > fax: (49-761)-203-2354) > Mathematics Institute of the Freiburg University > Albertstrasse, 23 b, Freiburg i.Br., D-7800, FRG > > E.I.Khukhro, V.D.Mazurov > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From dentzer@polyhymnia.iwr.uni-heidelberg.de Mon Jan 4 15:25:32 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Mon, 4 Jan 93 15:25:32 +0100 Subject: Re: GAPstones on Suns We have some higher GAPstone figures on our Suns, I think this is due to the gcc compiler we used to make gap, target "sun-sunos-gcc". With the GAP option -m 2m we get in the first run of combinat.tst: Model GAPstones SLC (20 MHz) 15272 1+ (25 MHz) 17758 4/280 (16 MHz) 15145 2 (40 MHz) 27888 10-20 (33 MHz) 46876 Ralf Dentzer dentzer@kalliope.iwr.uni-heidelberg.de From sl25@cus.cam.ac.uk Mon Jan 4 15:58:37 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Mon, 4 Jan 93 15:58:37 +0100 Subject: Re: GAPstones on Suns Using the standard executable I can add Sun IPX 23823 Sum 4/690 23635 (Cypress CY605 processor) Tonight I'll run it on my PC (386SX/16) and try for a new record lowest. Steve From sibley@math.psu.edu Tue Jan 5 09:14:31 1993 From: sibley@math.psu.edu "David Sibley" Date: Tue, 5 Jan 93 09:14:31 +0100 Subject: Character Tables I have been computing some character tables using CharTablePGroup. Is the order of the conjugacy classes in .conjugacyClasses the same as the order of columns in the table? The manual implies this, but does not say it directly. If not, how do I know which class in the group goes with which column in the table? Is there some way to get the (very nice) output of DisplayCharTable directed to a file? I've been using cut & paste to save them, but there must be a better way. (I realize there is a problem with what width to use.) What does the message #I TransformingPermutations: no bijection of row families mean? (This might not be exactly right. It's from memory.) I don't see it very often, though I've been using TransformingPermutations quite a bit, so I assume it's something unusual. From ahulpke@bert.math.rwth-aachen.de Tue Jan 5 10:16:36 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Tue, 5 Jan 93 10:16:36 +0100 Subject: Re: Character Tables In his letter David Sibley asked: > Is the order of the conjugacy classes in .conjugacyClasses the same as > the order of columns in the table? The manual implies this, but does > not say it directly. The order *is* the same, though the manual is somehow evasive in this point. All routines computing character tables of groups (i.e. CharTablePGroup and also the forthcoming Dixon-Algorithm) will use the order of the classes of the group. The only requirement is, that the class of the identity *must* be in the first position. If the classes are not yet given, the routines compute them, and use them in the computed order. However, be careful with SortClassesCharTable: In GAP 3.1 this will *not* rearrange the conjugacy classes of the group, given in 'Table.group'. This will be fixed in GAP 3.2. > Is there some way to get the (very nice) output of DisplayCharTable > directed to a file? I would suggest the following routine, which will do the required task. It is used by PrintCharTable(file,table); or --- alternatively --- by PrintCharTable(file,table,width); where width is the length of the rows of the final output device, e.g. the printer: PrintCharTable := function(arg) local file,table,width,screensize; file:=arg[1]; table:=arg[2]; if Length(arg)>2 then width:=arg[3]; else # this is the standard print width width:=80; fi; # get screen size screensize:=SizeScreen(); # resize screen SizeScreen([width,screensize[2]]); PrintTo(file,DisplayCharTable(table)); # resize screen to standard size SizeScreen(screensize); end; > What does the message > > #I TransformingPermutations: no bijection of row families > > mean? (This might not be exactly right. It's from memory.) I don't > see it very often, though I've been using TransformingPermutations quite > a bit, so I assume it's something unusual. > TransformingPremutations first tries to map the rows --- regarded as sets of their elements --- of the first matrix onto the rows of the second matrix. The existence of such a mapping is necessary for the existence of transforming permutations. The same observation is valid for the columns, thus the same test is done therefore. If one of these two tests fail --- which can be checked quite easily --- the two matrices cannot be equivalent. This will eliminate the need to start the (expensive) routine, trying to map the matrices onto each other. The meaning of the printed message is just a 'false', but it is a *fast* 'false'. I hope this helps, Alexander From martin@bert.math.rwth-aachen.de Wed Jan 6 12:00:57 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 6 Jan 93 12:00:57 +0100 Subject: Re: GAP on OS/2 2.0 Steve Linton, who did the port of GAP to MS-DOS, wrote to me about the subject of GAP on OS/2 2.0. No it won't. The DOS extender that lets it run in a flat 32-bit memory model is not compatible with OS/2 at all. However, an OS/2 version should not be difficult to do, as OS/2 provides a 32-bit memory model and a C compiler for it. If you can find someone with an OS/2 machine (at Essen maybe) it should be no harder than a port to another flavour of UNIX. Indeed I vaguely recall the OS/2 stuff claiming to be POSIX compatible, in which case no work at all should be needed. Steve So, if there is anybody reading this forum who has OS/2 2.0, a C compiler for it, and who is willing to try the port, contact me. I can provide some hints what needs to be done. Martin -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From oli@ernie.math.rwth-aachen.de Wed Jan 6 13:03:56 1993 From: oli@ernie.math.rwth-aachen.de "Oliver Bonten" Date: Wed, 6 Jan 93 13:03:56 +0100 Subject: Re: re commutators In reply to a question by K. Dennis, J. Neubueser wrote: > for all sporadic groups. Can one perhaps use character theory also for > verifying C_2 or C_3? I have no idea, so here is another question. If > so, we have plenty of charactertables and tools for handling them in > GAP. I don't think it is that easy to use character theory to verify C_2 or higher. Character theory gives results "up to conjugacy in G", which is sufficient for C_1, but not for C_2. A character theoretic verification of C_1 essentialy verifies that for given x_1 there is a conjugacy class (z) in G such that x_1 is in (z^-1)(z). Clearly , C_1 follows from this. For given x_1, x_2, there is hope to find a conjugacy class (z) such that x_1 and x_2 both are in (z^-1)(z), but this doesn't prove C_2, because you don't know if it is "the same z" you get this way for writing x_1 and x_2 as commutators. Nevertheless, GAP has been a very useful experimental tool for finding the conjugacy class (z) in my thesis, and for a verification of C_2 or higher, character theory will show you which conjugacy classes may contain the wanted element z and which can't. Oliver Bonten -- Heute hack ich, morgen crack ich, uebermorgen hol ich mir dem SysOp sein Login. Ach wie gut dass niemand weiss, dass ich oli@math.rwth-aachen.de heiss. From sl25@cus.cam.ac.uk Wed Jan 6 15:04:14 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Wed, 6 Jan 93 15:04:14 +0100 Subject: Lowest GAPStone rating? My PC (386SX/16) returns 1607 GAPStones, using GAPEXE.386 and my stripped (comments and extra spaces removed) libraries. Has anyone scored less? From sam@ernie.math.rwth-aachen.de Thu Jan 7 16:17:06 1993 From: sam@ernie.math.rwth-aachen.de "Thomas Breuer" Date: Thu, 7 Jan 93 16:17:06 +0100 Subject: In his answer to a question of David Sibley concerning some messages printed by 'TransformingPermutations' Alexander Hulpke did not tell the whole truth. Two rows are regarded to be equivalent if 'Sort' makes them equal. The equivalence classes of rows of a matrix are called its row families. Clearly if two matrices are permutation equivalent then every row family of the first matrix must consist of rows that are equivalent to the rows in a family of the other matrix, and the cardinalities of these families must be equal. The same of course holds for the columns of the matrices, but moreover it is also true for the restriction to every row family of the first matrix and its corresponding family in the second one; this might yield a finer distribution to column families, and the program in fact computes this one. These distributions of rows and columns are not just computed to test some necessary conditions of permutation equivalence, in order to avoid starting the algorithm whenever these tests fail. They are an essential part of the algorithm, namely they provide the translation of the problem to find transforming permutations into a problem completely formulated in terms of permutations. This problem is then solved by one of the backtrack search algorithms for permutation groups (very similar to the algorithm for the computation of a centralizer in a given permutation group). Thomas Breuer From bamblett@maths.ox.ac.uk Wed Jan 13 13:15:29 1993 From: bamblett@maths.ox.ac.uk "Jane Bamblett" Date: Wed, 13 Jan 93 13:15:29 +0100 Subject: OperationHomomorphism While testing an implementation of an algorithm for finding the p-core of a permutation group, I came acrss the following GAP peculiarity. Suppose we type the following GAP commands. gap> G := Group((1,2,3,4), (5,6,7,8));; gap> H1 := Operation(G, [1,2,3,4]); Group((1,2,3,4)) gap> f1 := OperationHomomorphism(G, H1);; Then, as expected, we get gap> Kernel(f1); Subgroup(Group((1,2,3,4), (5,6,7,8)), [(5,6,7,8)]) and everything looks fine. Now suppose that we wish to be a bit twisted and let the above group G act on the set [1..10] (so that we have two fixed points) and that we define H2 and f2 via the GAP commands gap> H2 := Operation(G, [1,2,3,4,9,10]); Group((1,2,3,4)) gap> f2 := OperationHomomorphism(G, H2);; Then we get: gap> PreImages(f2, TrivialSubgroup(H2)); Subgroup(Group((1,2,3,4), (5,6,7,8)), [(5,6,7,8), (1,2,3,4)]) gap> Kernel(f2) = G; true gap> Image(f2, (1,2,3,4)); (1,2,3,4) gap> (1,2,3,4) in Kernel(f2); true - a bit peculiar? Perhaps wishing to compute with G having fixed points as above is being perverse but perhaps it would be good if GAP could deal with perverse situations like this, or at least notify the user of the possibility of strange results. Any comments? Jane Bamblett From martin@bert.math.rwth-aachen.de Wed Jan 13 18:07:27 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 13 Jan 93 18:07:27 +0100 Subject: Re: OperationHomomorphism In her e-mail message of 13-Jan-93 Jane Bamblett writes Suppose we type the following GAP commands. gap> G := Group((1,2,3,4), (5,6,7,8));; gap> H2 := Operation(G, [1,2,3,4,9,10]); Group( (1,2,3,4) ) gap> f2 := OperationHomomorphism(G, H2);; gap> Kernel(f2) = G; true - a bit peculiar? Yes indeed. GAP does the following to compute the kernel of 'f2'. It sees that 'G' has three orbits on '[1,2,3,4,9,10]', namely '[1,2,3,4]', '[9]', and '[10]'. Thus it computes the stabilizers of 'G' on those orbits (e.g., 'Stabilizer( G, [1,2,3,4], OnTuples )') and the kernel is the intersection of those stabilizers. Now the stabilizers are 'Subgroup( G, [ (5,6,7,8) ] )', 'G', and 'G'. Unfortunately there is a bug in 'PermGroupOps.Intersection' for the case that one of the operands ('H') is the parent group of the other operand ('G'). In this case it simply wants to return 'G', but there is a typo, so it returns 'H' instead. This problem is already fixed in GAP 3.2. If you want to fix it in GAP 3.1, change the line 690 in file '/lib/permbckt.g' from K := ShallowCopy( H ); to read K := ShallowCopy( G ); Jane Bamblett continues: Perhaps wishing to compute with G having fixed points as above is being perverse but perhaps it would be good if GAP could deal with perverse situations like this, or at least notify the user of the possibility of strange results. Any comments? No, what you tried is not perverse at all. In GAP an operation must satisfy the following conditions. The domain of operation must be a list without duplicates (it need not be a set, i.e., it need not be sorted), the image of every point in under each element of the group must again lie in , the trivial element of must operate trivially on , and for all elements and of '(^)^ = ^(*)'. The function that computes the image of a point in under an element in must either be given as optional third argument, or the standard operation '^' is used (which can alternatively be specified by 'OnPoints'). Whenever those conditions hold you can use 'Operation' and 'OperationsHomomorphism' and the other functions described in chapter 8, no matter how may orbits or fixpoints has on . I think the code is usually optimized for the case that has only one orbit and no fixpoints though. From a few experiments it seems that may even be the empty list, but I wouldn't be willing to bet that this is always allowed. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From neil@dehn.mth.pdx.edu Thu Jan 14 21:38:42 1993 From: neil@dehn.mth.pdx.edu "John R. Neil" Date: Thu, 14 Jan 93 21:38:42 +0100 Subject: Using GAP in a PC Lab Environment I was wondering if anyone has had any success in getting GAP to operate in a lab environment. I have a lab filled with 30 PC workstations and 30 Mac workstations all running of a single Novell file server. The PC's are all 386 machines with 4MB of memory. When I try to run GAP, everything runs fine until I try to define a group. Then it just sits there for long periods of time not doing anything. It also is not interruptable. Is this just a feature of running the MSDOS version of GAP in a network environment? If anyone has had success using GAP off of a Novell network, I'd appreciate hearing what you've done. --John Neil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Neil, Graduate Teaching Assistant e-mail: neil@math.mth.pdx.edu Mathematics Department NeXTMail: neil@dehn.mth.pdx.edu Portland State University =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From dlj@maths.nott.ac.uk Fri Jan 15 12:22:56 1993 From: dlj@maths.nott.ac.uk "Dr D. L. Johnson" Date: Fri, 15 Jan 93 12:22:56 +0100 Subject: Re: a question to HNN extensions Dear Gap-forum, especially Toni. Yes, this is correct. The stable letter in an HNN-extension appears with exponent-sum zero in every relator and so has infinite order even in the abelianised group. Dave Johnson From dlj@maths.nott.ac.uk Fri Jan 15 12:30:52 1993 From: dlj@maths.nott.ac.uk "Dr D. L. Johnson" Date: Fri, 15 Jan 93 12:30:52 +0100 Subject: Re: group theory discussion Dear Gap-forum, There is an electronic forum for group-theoretical questions. It is called the "pub" and is run by Geoff Smith at Bath, UK. Dave Johnson From muellpe@mi.uni-erlangen.de Fri Jan 15 17:56:44 1993 From: muellpe@mi.uni-erlangen.de "Peter Mueller" Date: Fri, 15 Jan 93 17:56:44 +0100 Subject: Primitive Groups The list PGTable in the primitive groups library contains some useful data about the primitive groups of degree \le 50. In practice one often likes to know which class of the O'Nan Scott classification a primitive group belongs to. Wouldn't it be sensible to add this information as a further component? Additionally, generators of one of the (at most two) minimal normal subgroups would be fine, as GAP doesn't seem (or did I miss something?) to offer a convenient way to compute them. Peter ================================================================ Peter M\"uller Math. Institut Univ. Erlangen-N\"urnberg Bismarckstr. 1 1/2 8520 Erlangen From neubuese@samson.math.rwth-aachen.de Fri Jan 15 18:03:14 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Fri, 15 Jan 93 18:03:14 +0100 Subject: Re: group theory discussion Dear David, thanks for your two remarks in the gap-forum. In fact Geoff had also himself mentioned pub in a letter to the gap-forum and I for one have asked to be enrolled to it, but so far did not get a message from it. If you get any, please send me a copy. Kind regards Joachim From gcs@maths.bath.ac.uk Fri Jan 15 19:12:15 1993 From: gcs@maths.bath.ac.uk "Geoff Smith" Date: Fri, 15 Jan 93 19:12:15 +0100 Subject: Re: group theory discussion PLease do not inundate Joachim with copies of group-pub-forum@maths.bath.ac.uk discussion. His enrollment request disappeared down a hole somewhere. It never reached me. He is now enrolled and has been sent recent group-pub-forum correspondence. Geoff Smith From greil@guug.de Tue Jan 19 11:43:48 1993 From: greil@guug.de "Anton Greil" Date: Tue, 19 Jan 93 11:43:48 +0100 Subject: Re: group theory discussion > > PLease do not inundate Joachim with copies of > group-pub-forum@maths.bath.ac.uk discussion. > > Geoff Smith > Has me question about a conjugacy problem last week to the group-pub-forum produced such copies? Then there may be a bug somewhere in the configuration of the two mailing-lists. Regards, Anton Greil greil@guug.de From neubuese@samson.math.rwth-aachen.de Tue Jan 19 12:31:22 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 19 Jan 93 12:31:22 +0100 Subject: Re: group theory discussion No worry, there seems to be everything under control in the gap-forum, I certainly was not inundated by mail. Thanks for everybody's concern Joachim Neubueser From martin@bert.math.rwth-aachen.de Thu Jan 21 13:58:10 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Thu, 21 Jan 93 13:58:10 +0100 Subject: Re: Primitive Groups In his article of 1993/01/15 Peter M"uller writes: The list PGTable in the primitive groups library contains some useful data about the primitive groups of degree \le 50. In practice one often likes to know which class of the O'Nan Scott classification a primitive group belongs to. Wouldn't it be sensible to add this information as a further component? Additionally, generators of one of the (at most two) minimal normal subgroups would be fine, as GAP doesn't seem (or did I miss something?) to offer a convenient way to compute them. Several comments. 1) Sims says in his article "Computational methods in the study of permutation groups" in "Computational Problems in Abstract Algebra" (Proceedings Oxford 67, John Leech ed.), which contains the primitive groups of degree <= 20: Any primitive group G of degree n < 60 has a unique minimal normal subgroup N. So how comes you talk about "the (at most two) minimal normal subgroups"? Or am I misunderstanding something here? 2) If the primitive group G of degree p^k has an elementary abelian regular normal subgroup, this is can be computed as Core( G, SylowSubgroup( G, p ) ) Peter Neumann in his article "Some algorithms for computing with finite permutation groups" in "Proceedings of Groups - St. Andrews 1984" (E.F. Robertson & C.M. Campbell ed.) gives a better algorithm, which avoids the computation of the Sylow subgroup. But for the groups in GAP's primitive group library this simple approach seems to be ok. 3) If the primitive group G of degree p^k < 5^5 is not of the affine type the socle (i.e., because of 1) the minimal normal subgroup) is the last term in the derived series, and can be computed as d := DerivedSeries( g ); d[Length(d)]; 4) The library file 'grp/primitiv.grp' identifies the minimal normal subgroup, if it is again primitiv. For example for g := PrimitiveGroup( 28, 11 ); the corresponding line in 'grp/primitiv.grp' reads [28, 29484, 2, 01000, 2805, 2707, "PZL(2,27)", 148,151,156,171], it tells us (in encoded form in the 5. column) that the minimal normal subgroup is 'PrimitiveGroup( 28, 5 )', and thus we get is as AsSubgroup( g, PrimitiveGroup( 28, 5 ) ); If the fifth entry reads 'EABL' the minimal normal subgroup is elementary abelian, and thus we can apply 2). If the fifth entry is empty the minimal normal subgroup is not elementary abelian and not primitive, and thus we should apply 3). Hope this helps, Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From dfh@maths.warwick.ac.uk Thu Jan 21 23:48:34 1993 From: dfh@maths.warwick.ac.uk "Derek Holt" Date: Thu, 21 Jan 93 23:48:34 +0100 Subject: Re: Primitive Groups With reference to the recent discusssion on primitive groups, the smallest such group (in terms of both order and degree) which has two distinct minimal normal subgroups is in fact A5 x A5 in its permutation representation of degree 60 on a diagonal subgroup. Derek Holt. From C31801ST@wuvmd.wustl.edu Tue Jan 26 05:10:39 1993 From: C31801ST@wuvmd.wustl.edu "Edward Spitznagel" Date: Tue, 26 Jan 93 05:10:39 +0100 Subject: FactorsInt and 6th Fermat Number I tried factoring the 6th Fermat number using the code below and got F6 returned to me, suggesting that F6 is prime. Since one factor of F6 is 274177, this seems to contradict Section 10.20 of the documentation, which states that "FactorsInt is guaranteed to find all factors less than 10^6." gap> FactorsInt( 2^(2^6) + 1); [ 18446744073709551617 ] gap> (2^(2^6) + 1) / 274177; 67280421310721 gap> quit; I doubt that it makes any difference, but my hardware is a Turbo Color NeXTstation running NeXTSTEP 2.1. My version of GAP is 3.1, obtained as gapexe.next from SAMSON. Edward Spitznagel Department of Mathematics Washington University c31801st@wuvmd.wustl.edu From kaup@ccucvx.unican.es Tue Jan 26 14:00:12 1993 From: kaup@ccucvx.unican.es "Ansgar Kaup" Date: Tue, 26 Jan 93 14:00:12 +0100 Subject: FactorsInt and 6th Fermat Number I tried factoring the 6th Fermat number in order to check the result that Edward Spitznagel got with his NeXT and FactorsInt found the correct factors. I am using a SUN SPARC station 10 and got the executable from SAMSON aswell. So the bug must have something to do with Edwards Hardware or is contained in the executable obtained from SAMSON. Ansgar Kaup departamento de matematicas Universidad de Cantabria, Santander kaup@ccucvx.unican.es From sl25@cus.cam.ac.uk Tue Jan 26 14:57:50 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Tue, 26 Jan 93 14:57:50 +0100 Subject: Re: FactorsInt and 6th Fermat Number I think this problem has come up already. There was a bug in the library, for which Martin posted a patch. The patch may well be in the 3.1 patchlevel 3 library, so I suggest you get that if you are not using it already. Otherwise mail me directly and I'll fish out the patch from my mail logs. Steve Linton From martin@bert.math.rwth-aachen.de Tue Jan 26 17:40:11 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Tue, 26 Jan 93 17:40:11 +0100 Subject: Re: FactorsInt and 6th Fermat Number In his e-mail message of 1993/01/26 Edward Spitznagel wrote: I tried factoring the 6th Fermat number using the code below and got F6 returned to me, suggesting that F6 is prime. Since one factor of F6 is 274177, this seems to contradict Section 10.20 of the documentation, which states that "FactorsInt is guaranteed to find all factors less than 10^6." gap> FactorsInt( 2^(2^6) + 1); [ 18446744073709551617 ] gap> (2^(2^6) + 1) / 274177; 67280421310721 gap> quit; This is indeed a bug in the function 'IsPrime'. Since 'IsPrime(2^64+1)' returns 'true', 'Factors' doesn't even attempt to factor it. A fix for that bug is in the upgrade from GAP 3.1 patchlevel 2 to GAP 3.1 patchlevel 3, which is available as 'upg3r1p3.dif.Z' from 'samson.math.rwth-aachen.de'. More about the problem (i.e., the reason why 'IsPrime' failed), can be found in one of my e-mails to the GAP Forum, which is in the file 'forum92d.txt' (GAP Forum mails of 4th quarter 92), on 'samson.math.rwth-aachen.de' in the directory 'tmp' (not in 'pub/gap' as the rest of GAP). In his e-mail message of 1993/01/26 Ansgar Kaup answered I tried factoring the 6th Fermat number in order to check the result that Edward Spitznagel got with his NeXT and FactorsInt found the correct factors. I am using a SUN SPARC station 10 and got the executable from SAMSON aswell. So the bug must have something to do with Edwards Hardware or is contained in the executable obtained from SAMSON. I think the NeXT people would be quite offended by the idea that their hardware is to blame ;-). (Oh, and of course the executables we distribute never have bugs. Well, hardly ever ;-) Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Tue Jan 26 18:18:15 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Tue, 26 Jan 93 18:18:15 +0100 Subject: GAPstones Here is a selected list of GAPstones for various machines. Computer Model MHz Memory OS Compiler GAPstones by Atari ST520+ 8 4 MB TOS gcc 2.1 1168 M. Schoenert Apollo DN10000 ? ? SR10.3 ? 20625 R. Lewis DECstation 3100 20 32 MB Ultrix gcc 2.2 22590 M. Schoenert DECstation 5120 25 32 MB Ultrix gcc 2.2 24942 M. Schoenert IBM PC 386SX 16 ? DOS djgpp 1.05 1607 S. Linton IBM PC 386DX 33 ? DOS djgpp 1.05 6057 S. Rosenbrock IBM PC 486DX 33 ? DOS djgpp 1.05 9948 L. Soicher IBM PC 486DX 50 16 MB 386BSD gcc 2.3.3 32894 M. Schoenert IBM PC 486DX 50 16 MB DOS djgpp 1.09 ~32000 M. Schoenert IBM RS6000 950 ~40 lots AIX cc 41691 R. Dentzer HP 730 67 128 MB HP-UX 8 cc 63578 M. Schoenert NeXTstation 25 ? Mach ? 16484 G. Mess Sparc 4/280 40 32 MB SunOs gcc 2.1 15145 R. Dentzer SparcStation SLC ? ? SunOs ? 11962 M. Smith SparcStation SLC ? 12 MB SunOS ? 12477 D. Endico SparcStation SLC 20 16 MB SunOs gcc 2.1 15272 R. Dentzer SparcStation 1+ ? ? SunOs ? 14203 W. Nickel SparcStation 1+ ? ? SunOs ? 15032 M. Smith SparcStation 1+ ? ? SunOs ? 16739 D. Sibley SparcStation 1+ 25 24 MB SunOs ? 17758 R. Dentzer SparcStation ELC ? ? SunOs ? 19821 M. Smith SparcStation IPX ? 64 MB SunOS ? 23782 D. Endico SparcStation 2 ? ? SunOS ? 24013 A. Caranti SparcStation 2 40 32 MB SunOS gcc 2.1 27888 R. Dentzer SparcStation ? ? 64 MB SunOS ? 39772 A. Kaup SparcStation 10-20 33 32 MB SunOS gcc 2.1 47619 R. Dentzer SparcStation 10-31 ? ? SunOs ? 44917 M. Smith SparcStation 10-30 ? ? SunOS ? 48329 W. Nickel A few remarks: The Atari ST520+ is the slowest machine. It is more than a factor of 50 slower than the fastest machine (a HP 730). Note that quite a bit of development of GAP was done on this machine (it is the one I have at home). Compilation (with optimization) of the entire GAP kernel takes over 4 hours on this machine. There is a big difference between L. Soicher's result for a 486DX33 and our result for 486DX50. One would expect that the 486DX50 is 50% faster, but not that it is more that 3 times faster. The reason is the following. In regular intervals (actually whenever a loop body is executed) GAP checks whether the user wants to interrupt the computation. Under UNIX this means checking a variable that is set by the signal handler for '-C'. Unfortunatly this is not possible under DOS/GO32 (or is it? 'setcbrk' might do what we want, but the documentation of DJGPP only says that there is such a function, not what it does). Thus under DOS GAP checks whether the user has pressed a key, and if so, whether it was '-C'. Now checking whether a key was pressed requires a system call ('kbhit()'), which means that GO32 (the DOS extender) has to switch from protected mode (in which GAP runs) to real mode (which DOS wants). This is a *very* expensive operation. So expensive, that GAP 3.1 spent more than half of the time it took to execute 'combinat.tst' switching from protected mode to real mode and back again. In 3.2 we have changed GAP so that only every 20th check actually does call 'kbhit()'. This made GAP more than a factor of 2 faster. And the time between pressing '-C' and GAP responding is still small enough. The results for SparcStations vary somewhat. I think this has to do with the compiler used. GNU CC 2.x seems to be best. The NeXTstation is actually faster than the above result would indicate. Namely, one has to use GNU CC 2.x, instead of the compiler that comes with the operating system, which is GNU CC 1.39 (I think). However, installation of GNU CC 2.x is not a trivial task (or so I am told, there seems to be some problem with precompiled header files). Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From kaup@ccucvx.unican.es Wed Jan 27 10:37:43 1993 From: kaup@ccucvx.unican.es "Ansgar Kaup" Date: Wed, 27 Jan 93 10:37:43 +0100 Subject: Sorry Sorry for not believing in executables distributed not containing bugs but I didn't think of not-applicated updates. Ansgar Kaup From neil@dehn.mth.pdx.edu Wed Jan 27 17:12:23 1993 From: neil@dehn.mth.pdx.edu "John R. Neil" Date: Wed, 27 Jan 93 17:12:23 +0100 Subject: Running GAP on MSDOS systems A couple of weeks ago I posted to this group the problems I was experiencing running GAP in our lab full of PC's on a Novell network. The problem turned out to be completely unrelated to the use of a network. It turns out that GAP is unable to run correctly if EMM386 is in the CONFIG.SYS file. The GO32 extender is incompatible with this extended memory management tool. A warning should perhaps be placed in the documentation warning users of this conflict. I have removed this device driver from the PC's in my lab and now GAP runs perfectly (at, of course, 386-25 speed...). --John Neil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Neil, Graduate Teaching Assistant e-mail: neil@math.mth.pdx.edu Mathematics Department NeXTMail: neil@dehn.mth.pdx.edu Portland State University =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From martin@bert.math.rwth-aachen.de Wed Jan 27 17:52:06 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 27 Jan 93 17:52:06 +0100 Subject: Re: Running GAP on MSDOS systems I can't check right now, but I'm pretty certain that we run GAP with 'EMM386' in 'config.sys'. Somewhere in the documentation for 'djgpp' it says that you cannot use the 'noems' switch, whatever that means. Also I think that if GAP has problems with the memory manager it would not even start, while you report that the problems appear once GAP tries to read a file. Of course if GAP now works in your lab, you may not want to experiment further (if it ain't broke ...), on the other hand I wonder how much memory GAP can use if you run no memory manager. Maybe only 640 kByte, and when it needs more it starts paging (ouch)? Martin. PS. I have this theory about why Bill Gates is so rich. Secretly every programmer who makes a living from writing a program that fixes a problem or a deficiency in MSDOS has to pay Bill Gates 10% of his income. Well maybe it's only 1%. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From sl25@cus.cam.ac.uk Fri Jan 29 16:05:28 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Fri, 29 Jan 93 16:05:28 +0100 Subject: Re: Running GAP on MSDOS systems -------- There are two or three different programs EMM386 around. In particular the one you get with Windows 3.00 is deficient. You should replace it with the one that comes with DOS 5.00a. Better still get the Quarterdeck product QEMM386. Steve From neil@dehn.mth.pdx.edu Fri Jan 29 22:37:44 1993 From: neil@dehn.mth.pdx.edu "John R. Neil" Date: Fri, 29 Jan 93 22:37:44 +0100 Subject: Re: Running GAP on MSDOS systems In message you write: >-------- > >There are two or three different programs EMM386 around. In >particular the one you get with Windows 3.00 is deficient. You >should replace it with the one that comes with DOS 5.00a. Better >still get the Quarterdeck product QEMM386. > > Steve > We were using the one which comes with DOS 5.0. The main problem with EMM386 (no matter who's you use) is that their behavior, particularly with many TSR's running (as you need to have when attached to a network), is extremely unreliable and unpredictable. Problems will work just fine until they wish to access EMM and then they crash. Or sometimes they work reliably for the first several calls and then crash. We have found that in many cases if a program is having any problems that are memory related, get rid of whatever version of EMM386 you are using and everything will work just fine. As far as GAP starting to page, I believe that DJGPP has it's own memory management stuff built in to the 32-bit extender. Thus, EMM386 is totally unnecessary anyway. --John Neil PS. 386MAX causes GAP to immediately lock up upon execution. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Neil, Graduate Teaching Assistant e-mail: neil@math.mth.pdx.edu Mathematics Department NeXTMail: neil@dehn.mth.pdx.edu Portland State University =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From dentzer@polyhymnia.iwr.uni-heidelberg.de Mon Feb 1 10:06:51 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Mon, 1 Feb 93 10:06:51 +0100 Subject: Re: GAPstones Just a little correction. The line Sparc 4/280 40 32 MB SunOs gcc 2.1 15145 R. Dentzer should read Sparc 4/280 16 40 MB SunOs gcc 2.1 15145 R. Dentzer i.e. the machine has 40 MB of main memory and a frequency of 16 MHz. And as I am just at it, do the authors of "combinat.tst" know what is mainly measured by this benchmark? From a gprof it seems that most of the time is spent in the GAP Interpreter (>50 %) and only very little for doing arithmetic and memory management (<5 % each). Does this reflect time usage of typical GAP routines? What about permutations, AG groups, finite fields, cyclotomic fields? Thanks Ralf Dentzer dentzer@kalliope.iwr.uni-heidelberg.de From martin@bert.math.rwth-aachen.de Tue Feb 2 17:22:36 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Tue, 2 Feb 93 17:22:36 +0100 Subject: Re: Re: GAPstones In his e-mail message of 1993/02/01 Ralf Dentzer writes: And as I am just at it, do the authors of "combinat.tst" know what is mainly measured by this benchmark? From a gprof it seems that most of the time is spent in the GAP Interpreter (>50 %) and only very little for doing arithmetic and memory management (<5 % each). Does this reflect time usage of typical GAP routines? What about permutations, AG groups, finite fields, cyclotomic fields? It is quite difficult to say what a typical use of GAP is. For example, if one works with permutation groups of degree over 100, one sees an entire different picture. On the other hand, computations with character tables that involve only very few irrationalities might actually show a similar distribution (I never tried this though). And the answer is, yes, we are aware of the specific distribution of "combinat.tst". But we have found that the performance reported by "combinat.tst" is reasonably close to our ``feeling'' of how fast the machines we have tried it on are. Actually one can even be a bit more specific. Here is the output of 'pixie' (the most accurate profiling tool, because it actually counts cycles, unfortunately only available on machines with the MIPS processor) for GAP 3.1 running "combinat.tst". The first column contains the number of cycles, the second the percentage of the total number of cycles, the third the number of calls, and the fourth the name of the function. I have grouped the functions according to the package they belong to, and have ommitted functions whose percentage was below 0.1%. Interpreter (eval 22.08%, function 19.83%, statemen 14.59%) 33595913 7.65 2584301 EvVar (eval.c) 9776625 2.23 196075 Eq (eval.c) 9435970 2.15 190798 Diff (eval.c) 9324288 2.12 181912 Sum (eval.c) 8133406 1.85 71330 FunShallowCopy (eval.c) 6900221 1.57 188588 EvVarAss (eval.c) 6238983 1.42 143309 EvAnd (eval.c) 5070936 1.15 101630 EvOr (eval.c) 2867693 0.65 39239 Prod (eval.c) 2094182 0.48 38040 Ne (eval.c) 1875496 0.43 33166 Le (eval.c) 435759 0.10 6307 Mod (eval.c) 55270007 12.59 250223 EvFunccall (function.c) 28437062 6.48 183380 ChangeEnv (function.c) 3205685 0.73 91591 EvReturn (function.c) 38293896 8.72 266957 EvIf (statemen.c) 17140123 3.90 53408 EvFor (statemen.c) 8393290 1.91 89811 EvStatseq (statemen.c) Memory Management (gasman 21.51%) 33964602 7.74 308242 NewBag (gasman.c) 32295304 7.36 10 CollectGarb (gasman.c) 11116554 2.53 362625 ExitKernel (gasman.c) 8523620 1.94 57558 Resize (gasman.c) 4714125 1.07 362625 EnterKernel (gasman.c) 2938674 0.67 186597 NrHandles (gasman.c) 873862 0.20 1 InitGasman (gasman.c) Lists (list 16.99%, vector 0.02%) 31478498 7.17 379801 EvListElm (list.c) 19866656 4.52 162053 EvListAss (list.c) 13102065 2.98 60932 FunAppend (list.c) 5375002 1.22 68101 MakeList (list.c) 1429617 0.33 68077 EvMakeList (list.c) 1249837 0.28 12062 FunAdd (list.c) 946479 0.22 4636 PosList (list.c) Arithmetic (integer 1.21%, rational 0.17%) 1469833 0.33 24474 QuoInt (integer.c) 1396376 0.32 27243 ProdInt (integer.c) 1194533 0.27 16211 GcdInt (integer.c) 524400 0.12 4930 SumInt (integer.c) 423835 0.10 4678 QuoRat (rational.c) Reading (scanner 1.38%, read 0.54%, indents 0.2%, system 0.54%, libc 0.87%) 2086621 0.48 19636 GetSymbol (scanner.c) 1383089 0.31 7972 GetIdent (scanner.c) 924253 0.21 24385 PutChr (scanner.c) 745285 0.17 5104 Pr (scanner.c) 881700 0.20 5460 FindIdent (idents.c) 1133070 0.26 226614 SyIsIntr (system.c) 855227 0.19 4319 SyFgets (system.c) 2982948 0.68 4317 fgets (../fgets.c) A total of 56.5% of the running time are spent in the interpreter. There most of the time is spent evaluating function calls ('EvFunccall' and 'ChangeEnv'). This is because most of the functions in the combinatorics package work in a highly recursive manner, and thus the number of function calls is unusually high. (Looking at the number of calls to 'ChangeEnv' (which is called twice by 'EvFunccall' for every non-internal GAP function), one sees that 91690 calls are calls to GAP functions, and the remaining 158533 are calls to internal functions: 71330 'ShallowCopy', 60932 'Append', 12062 'Add', 5439 'Length', 4004 'Position', 2071 'IsList', 1976 'IsFunc', and 719 others. Comparing the numbers for 'ChangeEnv' and 'EvReturn' we see that there were 99 calls to functions which did not return anything, most likely they are all calls to 'Sort'. Finally note that both 'EvIf' and 'EvFor' have 'EvStatseq' inlined, i.e., they do not call 'EvStatseq' to evaluate their bodies. So the number of calls of 'EvStatseq' reflects the number of calls to GAP functions that have more than a single statement in their body. So comparing the numbers for 'ChangeEnv' and 'EvStatseq' we see that about 1880 calls where to functions with only a single statement in their body, e.g., functions of the form ' -> '.) 'EvVar' contributes a large percentage of the total running time, simply because it is call so often. Improving the speed of 'EvVar' would therefor speed up GAP quit a bit. Unfortunately 'EvVar' is already as minimal as it can be. All in all the amount of time spent in the interpreter is much higher than one would expect from other computations. Especially the large number of function calls is not typical. The memory management uses 21.5% of the total running time. 288655 of the 308242 created bags ('NewBag') are easily accounted for: 91690 from 'EvFunccall', 71330 from 'ShallowCopy', 68077 from 'MakeList', and 57558 from 'Resize' calls. Note that the number of calls to 'Resize' is again unusually high. (We are thinking about a new memory manager (Ralf has actually provided a prototype for such a memory manager). This new memory manager will make 'NewBag' a lot faster (probably a factor of 5 or so). 'NewBag' will also become a macro, so that it will be more difficult to see its influence in future profiles. 'CollectGarb' will become faster (because it will use generations), 'ExitKernel' and 'EnterKernel' will no longer be neccessary, and the number of calls to 'NewBag' will also be reduced (because it is called most of the time from 'CollectGarb'). So I think that the cost for memory management for this test could be reduced to well below 10% with this new memory manager.) Other computations will usually spent less time in the memory management, unless most of the objects allocated are rather small, such as in this computation. And of course, if the workspace is too small, so that too many garbage collections are neccessary, the percentage of time spent in 'CollectGarb' can become arbitrarily high (I remember a Schreier Sims computation which I once did on my Atari, where a garbage collection was neccessary each time after allocating 20 permutations). Now "combinat.tst" mainly works with lists (of integers), thus it is not surprising that 17% of the total time is spent in the list package. Especially the number of assignments to list elements is way above the norm. Again all in all one would expect other computations to spent less time in the list package. But since lists are the main data structure in GAP almost all computations spent quite a bit of their time in this package. The amount of time spent in the arithmetic is small. This is because arithmetic of immediate integers (i.e., -2^28 <= n < 2^28) is done in 'Eq', 'Sum', 'Diff', etc., without calling other functions. What you see in 'SumInt', etc. are only the few computations that involve large integers (e.g., Binomial( 400, 50 )). Other computations that involve a lot of large integers, rationals, cyclotomics, permutations, words, etc., will probably spent most of their time in the respective arithmetic package. And of course the time spent reading is very small. If you only do a small computation with a group (where the whole library must first be read in), this would contribute a much higher amount. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From L.H.Soicher@qmw.ac.uk Thu Feb 4 15:57:23 1993 From: L.H.Soicher@qmw.ac.uk "Leonard Soicher" Date: Thu, 4 Feb 93 15:57:23 +0100 Subject: new version of GRAPE GRAPE (GRaph Algorithms using PErmutation groups) A new version of GRAPE is available via anonymous ftp from IP number 138.37.80.15. It is in the pub directory in files grape.README and grape.tar.Z. Please read grape.README. Also, GRAPE includes some TeX documentation to get you started. If you collect this version of GRAPE and set it up (or have problems setting it up), please email me to this effect. Notes: This version of GRAPE is an improved and expanded version of that released in August, 1992. All known bugs are fixed: the only bug which was not minor was in QuotientGraph, but this bug should not have caused incorrect results when the quotient map was a covering map or when the group associated with the graph to be quotiented was trivial. L.H.Soicher@qmw.ac.uk From muellpe@mi.uni-erlangen.de Sun Feb 7 18:55:03 1993 From: muellpe@mi.uni-erlangen.de "Peter Mueller" Date: Sun, 7 Feb 93 18:55:03 +0100 Subject: Normalizer doesn't normalize? Do I misunderstand something? gap> Parent(g)=Parent(hp); true gap> g=Parent(g); true gap> np:=Normalizer(g,hp);; gap> IsNormal(np,hp); false ================================================================ gap> g; Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,10,15), ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)( 2,21) ( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ) gap> hp; Subgroup( Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4, 10,15), ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19) ( 2,21)( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ), [ ( 1,15,16, 5,11,13,17)( 2,18, 4,21, 9,14, 8)( 3, 6,20,19,10, 7,12), (), ( 2, 9)( 3,20)( 5,11)( 7,10)( 8,14)(12,19)(13,16)(15,17)(18,21), ( 1, 3,21,11,12,14)( 2, 5, 6,18,15, 7)( 4,17,20, 8,13,10)( 9,16,19) ] ) gap> quit; Peter From neubuese@samson.math.rwth-aachen.de Mon Feb 8 13:53:03 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Mon, 8 Feb 93 13:53:03 +0100 Subject: Re: Normalizer doesn't normalize? Peter Mueller writes: > > Do I misunderstand something? > > gap> Parent(g)=Parent(hp); > true > gap> g=Parent(g); > true > gap> np:=Normalizer(g,hp);; > gap> IsNormal(np,hp); > false > > ================================================================ > > gap> g; > Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4,10,15), > ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19)( 2,21) > ( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ) > gap> hp; > Subgroup( Group( ( 1, 7,12,16,19,21, 6)( 2, 8,13,17,20, 5,11)( 3, 9,14,18, 4, > 10,15), ( 1, 2)( 3, 6)( 8,15)( 9,13)(10,14)(11,12)(16,20)(17,21), ( 1,19) > ( 2,21)( 3,15)( 4,20)( 5,14)( 6,13)( 7,17)(11,16)(12,18) ), > [ ( 1,15,16, 5,11,13,17)( 2,18, 4,21, 9,14, 8)( 3, 6,20,19,10, 7,12), (), > ( 2, 9)( 3,20)( 5,11)( 7,10)( 8,14)(12,19)(13,16)(15,17)(18,21), > ( 1, 3,21,11,12,14)( 2, 5, 6,18,15, 7)( 4,17,20, 8,13,10)( 9,16,19) ] ) > gap> quit; > > > Peter This bug does not occur any more in the present GAP 3.1 and will also not occur in GAP 3.2 (to be released *soon*!!!). A bug in the normalizer program was fixed in patchlevel 2 for 3.1, which is available since June 2, 1992. So the reported bug refers most likely to a copy of GAP that has not been corrected with the above-mentioned patch. Joachim Neubueser From dana@bimacs.cs.biu.ac.il Wed Feb 10 15:09:43 1993 From: dana@bimacs.cs.biu.ac.il "Dana-Picard Noah" Date: Wed, 10 Feb 93 15:09:43 +0100 Subject: products I'm a very new user of GAP and try to run it on 486. 1) If H and K are two subgroups of G, what is the easiest way of computing their product HK as a subgroup of G? 2) Does it exist some kind of tutorial for the beginner? Thanks a lot, Thierry Dana-Picard. From neubuese@samson.math.rwth-aachen.de Wed Feb 10 17:00:50 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Wed, 10 Feb 93 17:00:50 +0100 Subject: Re: products Let me answer your questions: > Subject: products > > I'm a very new user of GAP and try to run it on 486. > 1) If H and K are two subgroups of G, what is the easiest way of > computing their product HK as a subgroup of G? > 2) Does it exist some kind of tutorial for the beginner? > Thanks a lot, > Thierry Dana-Picard. ad 1): Usually the notation HK for two subgroups H and K is used to mean the *set* of all elements hk with h in H and k in K. This is a subgroup only if HK = KH. If this is the case, then the command Closure(H,K) will compute this *subgroup* HK, as described in section 7.17 (pages 227/8) of the manual. If HK is *not* a subgroup ( as would alredy happen if you take two cyclic subgroups of order 2 in the symmetric group of degree 3) then there is *no* GAP command to compute this set, you would have to create this *set* by a little self-written function. ad 2): There is no special tutorial for GAP, however chapter 1 of the manual, called "About GAP" (pages 37 -150) provides an easy introduction to GAP. Further you may be interested that a Summer School on Computational Group Theory using GAP as the main vehicle is planned as part of the 'Groups 1993, Galway/St.Andrews' meeting to be held in Galway, Ireland, August 1 to 14. Joachim Neubueser From caranti@volterra.cineca.it Thu Feb 11 16:00:58 1993 From: caranti@volterra.cineca.it "Andrea Caranti" Date: Thu, 11 Feb 93 16:00:58 +0100 Subject: combinat.tst Dear gap-forum, I just got a new Sun SparcStation 10/41, with 64MB of RAM, running under Solaris 1.1 at 40MHz. I ran combinat.tst with the standard 4MB and got exactly 50000 GAPstones for the first run, and 50787 for the second one. I was using the pre-compiled GAP kernel from Aachen. I will try to recompile GAP on the machine, and see what I get. Yours, A Caranti From L.H.Soicher@qmw.ac.uk Thu Feb 11 18:31:49 1993 From: L.H.Soicher@qmw.ac.uk "Leonard Soicher" Date: Thu, 11 Feb 93 18:31:49 +0100 Subject: Blist functions The functions UnionBlist, IntersectionBlist, and DifferenceBlist dont't appear to be defined! L.H.Soicher@qmw.ac.uk From martin@bert.math.rwth-aachen.de Thu Feb 11 18:39:54 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Thu, 11 Feb 93 18:39:54 +0100 Subject: Re: Blist functions 'UnionBlist' etc. are defined in GAP 3.2. But 'UniteBlist' etc. are usually better (because they don't allocate new objects). Thanks, Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From michel@dmi.ens.fr Fri Feb 12 13:13:17 1993 From: michel@dmi.ens.fr "Jean Michel" Date: Fri, 12 Feb 93 13:13:17 +0100 Subject: problem with empties in GAP I hope it is not too late to ask for some small fixes for what I consider to be a bug in the design of some gap functions. To show why I consider this feature to be a bug, I will show some examples of programs where I had to add ugly code to get around it -- then you can argue against me constructively by showing me how I should have written my code. Example 1: Given a list l1,..lr of integers (with no holes -- recognized as a vector by Gap) I want to construct the list (1,..,d,l1+d,...,lr+d). So I wrote: gap>shift:=function(l,d)return Concatenation([1..d],l+d);end; What is the problem? This does not work when l is empty: I get "Error, Vectors: '+' incompatible types" Indeed, when asked: gap>IsVector([]); false Is not this wrong? The vector space of dimension 0 is a perfectly valid mathematical object -- How to represent its elements? I had to write: plus:=function(a,b) if Length(a)=0 then return a; elif Length(b)=0 then return b; else return a+b; fi; end; and use it in many places instead of '+' (and similarly for '-'). Is not this ugly (and inefficient)? Example 2: I need to compute an echelonized basis of the space generated by a set of vectors. If s is this set (represented as a list of vectors), TriangulizeMat(s) works well excepted when the set is empty: gap>TriangulizeMat([]); Error, ... because in the code of the function Length(mat[1]) is taken. Would not it be easy to fix it so that TriangulizeMat([])=[] ? Discussion: these 2 examples seem to me a symptom of a wrong treatment of empties in GAP, which forces to add ugly and unnecessary code to handle special cases. GAP has only one kind of empty, the list [] (in contrast to languages like APL where an empty matrix still may have a shape like [0,5]). This is fine with me, but then all operations which logically should accept empty vectors(or matrices, or whatever...) should also accept []. I cannot see any big problem with IsVector([]) being true, but it being false certainly gives me problems. Jean MICHEL, D.M.I., E.N.S - Paris From martin@bert.math.rwth-aachen.de Fri Feb 12 17:48:24 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Fri, 12 Feb 93 17:48:24 +0100 Subject: Re: problem with empties in GAP In his e-mail of 1993/02/12 (actually it arrived here a little bit earlier, but not from his subscription address, so I had to stuff it into 'listserv' by hand) Jean Michel asks why GAP doesn't allow vectors of length zero. He writes: Given a list l1,..lr of integers (with no holes -- recognized as a vector by Gap). I want to construct the list (1,..,d,l1+d,...,lr+d). So I wrote: gap>shift:=function(l,d)return Concatenation([1..d],l+d);end; What is the problem? This does not work when l is empty: I get "Error, Vectors: '+' incompatible types" Actually this will work in GAP 3.2, but it probably should not be relied upon to work in later releases. He continues Indeed, when asked: gap>IsVector([]); false Is not this wrong? The vector space of dimension 0 is a perfectly valid mathematical object -- How to represent its elements? I beg to differ. The vector space of dimension 0 *over a given field* is a perfectly valid object. But if we represent vectors in such a vector space by lists of length zero we have way to find the field this vector lies in. Why is this a problem? Well, what is the scalar product of two empty vectors? Zero, of course. But which zero? The integer zero, or the zero from a finite field (but of which characteristic), or the zero polynomial over some ring? This is basically the problem. We have no way to find a field for such an empty vector (and thus the zero). He contiunes: Example 2: I need to compute an echelonized basis of the space generated by a set of vectors. If s is this set (represented as a list of vectors), TriangulizeMat(s) works well excepted when the set is empty: gap>TriangulizeMat([]); Error, ... because in the code of the function Length(mat[1]) is taken. Would not it be easy to fix it so that TriangulizeMat([])=[] ? Yes, it would be easy to fix 'TriangulizeMat', and I see no problem with this. Expect this to happen in the near future. He continues: these 2 examples seem to me a symptom of a wrong treatment of empties in GAP, which forces to add ugly and unnecessary code to handle special cases. GAP has only one kind of empty, the list [] (in contrast to languages like APL where an empty matrix still may have a shape like [0,5]). This is fine with me, but then all operations which logically should accept empty vectors(or matrices, or whatever...) should also accept []. I would formulate this slightly different (though I agree that there is a problem). In GAP certain information about a vector or a matrix is simply implicit. For example with vectors the field over which this vector lies is derived from the entries of this vector. This is why a vector must have at least one entry. Another example are matrices. The shape of a matrix is derived from its length and the length of its rows. Lets for the moment assume that vectors of length zero were legal. Then we could create a matrix of shape [5,0], namely [[],[],[],[],[]]. But we could not create a matrix of shape [0,5], because how could GAP guess that each row has length 5, if the matrix has no rows. Because GAP tries to read of information (the field and the dimension) about a vector or a matrix from the entries (the elements or the rows) such a field or matrix may not have zero length. In spite of this problem I still think that GAP's approach is a good one. In GAP 2.4 vectors and matrices were different datatypes, and the neccessary conversions between lists (of lists) and vectors or matrices were quite a pain. In GAP 3, where everything is just a list, you have all the powerfull list operations and functions available to apply to vectors, matrices (and sets too). You can simple extract elements from a matrix with m[i][j] or change them with an assignment (which you could not in GAP 2.4). He continues: I cannot see any big problem with IsVector([]) being true, but it being false certainly gives me problems. I hope I could convince that there are problems. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From borbor@divsun.unige.ch Sat Feb 13 07:48:28 1993 From: borbor@divsun.unige.ch "Borcic Boris" Date: Sat, 13 Feb 93 07:48:28 +0100 Subject: GAP for MAC, new version ? I think I recall a new version of GAP for the Macintosh was promised maybe mid-december for maybe mid-january by the authors of the original port. Is it still in the works ? Regards, Boris Borcic --- (12^2-55)^2-12^2*55-1=0 From smith@pell.anu.edu.au Mon Feb 15 05:00:32 1993 From: smith@pell.anu.edu.au "Michael Smith" Date: Mon, 15 Feb 93 05:00:32 +0100 Subject: Running GAP in Emacs buffer. GAP and Emacs users: I have just finished writing a GAP process mode for running an interactive GAP session in an Emacs buffer. This code is based on the GAP mode of Goetz Pfeiffer, which I modified to use comint-mode instead of shell-mode. GAP's command completion and help are available. Both the help and lists of completions are shown in separate buffers from the GAP session, and help can be evoked at any time (on any topic, defaulting to current command) by pressing "?". The file gap-process.el is available by anonymous ftp from pell.anu.edu.au in directory pub/gnu/elisp. Note that it requires the comint-mode package by Olin Shivers to work. Follow the instructions in the comments at the start of the file for installation instructions. Cheers, Michael. From michel@dmi.ens.fr Mon Feb 15 10:37:30 1993 From: michel@dmi.ens.fr "Jean Michel" Date: Mon, 15 Feb 93 10:37:30 +0100 Subject: Re: problem with empties in GAP Excuse me for this long message -- I reply to the reply to my message, and to make things celar I quote extensively both. I said: >>> I hope it is not too late to ask for some small fixes for what I consider >>> to be a bug in the design of some gap functions. To show why I consider this >>> feature to be a bug, I will show some examples of programs where I had to >>> add ugly code to get around it -- then you can argue against me >>> constructively by showing me how I should have written my code. >>> Example 1: >>> Given a list l1,..lr of integers (with no holes -- recognized as a vector by >>> Gap) I want to construct the list (1,..,d,l1+d,...,lr+d). >>> So I wrote: >>> >>> gap>shift:=function(l,d)return Concatenation([1..d],l+d);end; >>> >>> What is the problem? This does not work when l is empty: I get >>> >>> "Error, Vectors: '+' incompatible types" >>> Martin Schoenert says: >> Actually this will work in GAP 3.2, but it probably should not be relied >> upon to work in later releases. >> What does this mean? >>> Indeed, when asked: >>> >>> gap>IsVector([]); >>> false >>> >>> Is not this wrong? The vector space of dimension 0 is a perfectly valid >>> mathematical object -- How to represent its elements? >>> Martin says >> I beg to differ. The vector space of dimension 0 *over a given field* is >> a perfectly valid object. But if we represent vectors in such a vector >> space by lists of length zero we have way to find the field this vector >> lies in. >> >> Why is this a problem? Well, what is the scalar product of two empty >> vectors? Zero, of course. But which zero? The integer zero, or the >> zero from a finite field (but of which characteristic), or the zero >> polynomial over some ring? This is basically the problem. We have no >> way to find a field for such an empty vector (and thus the zero). >> This answer seems to me unnecessarily confused. It seems to reinforce my point that the design of GAP in this area has not been well thought out. It is possible to adopt different viewpoints of the situation: -pure object-oriented: everything has a type, then a vector is necessarily a vector of something, and Martin's criticism is fully valid; also the design of GAP is then terribly flawed since this type is not explicitely present in the object vector, which is thus mostly unusable. -functional: a unique data model (list) serves a variety of purposes. Type information is given by context. This is the viewpoint I have adopted to try to make sense of the design of GAP. Then the problem raised by Martin does not exist: we don't have to find the type of an empty object, but the type the context requires, if any: e.g.: - add a (possibly empty) vector to a number: if the vector is nonempty, use the type of the vector's elements otherwise that of the number. - scalar product of two empty vectors: no type information given by context, it is reasonable to give an error. It would be very useful, though, to have as answer an object which could serve as zero in a variety of fields and rings. - TriangulizeMat([]): no type information given by context, but none required either, since result is empty. - And now the big one: IsVector([]): The context clearly requires 'true' ! From neubuese@samson.math.rwth-aachen.de Mon Feb 15 17:31:02 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Mon, 15 Feb 93 17:31:02 +0100 Subject: Re: problem with empties in GAP Dear Professor Michel, I am answering your letter of February the 15.th to the GAP forum since Martin Schoenert is absent from Aachen for the next two weeks. Let me first summarize the point of the discussion as I see it, namely the question in how far GAP supports the interpretation of empty lists as vectors and allows typical vector operations with them. At the end of today's letter you offer two different viewpoints of the situation: First the "pure object-oriented: everything has a type ...". This is clearly not the viewpoint adopted in GAP 3.1 for the interpretation of lists as vectors, as Martin Schoenert explained to you in his letter. Such a puristic viewpoint had been tried in GAP 2.4 and has been discarded and removed in the transition from 2.4 to 3.0 since we learned by experience that it created a lot of practical problems. In so far it is unnecessery to state that if this was the viewpoint taken then the design of GAP would be terrible flawed. This viewpoint is not taken, you know it and Martin said it. Second the "functional: a unique data model (list) serves a varity of purposes...". This is indeed the viewpoint presently taken in GAP, and again Martin has explained this. Also indeed in a number of cases, GAP does try to use the context in order to interpret what an operation should mean in situations where, from a strict mathematical point of view, the operation is not defined. For instance, if you want to multiply an integer by a finite field element, GAP does return a finite field element although, strictly speaking, the two factors are from different domains. All you seem to ask for is an extension of the ability of GAP to "guess" from the context what is meant. That this is indeed all you ask for is demonstrated by the fact that you are willing to allow an error message in case of a scalar product of two "empty vectors". GAP did return an error message in a place where it disturbed you, but in principle the two places aren't all that different. Such request as shown by the problems that you mention in your first letter is certainly reasonable and ought to be discussed if problems of the commodity of using GAP have arisen as it has been the case with you. I do not think, however, that such a request is a reason to use in a public worldwide discussion terms like you have chosen in your letters, like talking of "a wrong treatment of empties" or "an unnecessary confused answer" and the like. While we are grateful for each notification of a real bug, and while we appreciate every suggestion for the improvement of GAP, I am not willing to accept that users of GAP use a tone in the discussion with us like an impatient teacher may (but should not) use with a dumb student. In detail: Martin's answer that adding an integer to an empty list will work in GAP 3.2 but one should not rely upon this to work in later releases means: This possibility --which will not be mentioned in the manual of GAP 3.2-- exists in GAP 3.2 but the rather difficult question how to treat such border cases as addressed by you under the present viewpoint of GAP in more generality may find another answer later, forced upon by further experience. As to the possibility of doing the kind of operations you would like to have with empty vectors: GAP offers you to define a new data type "vector over a fixed field and of fixed dimension" using records in a similar way to the one explained in the section "About Defining new Group Elements". Of course some functions have to be written for that, and also it has to be expected that operations for this new type will be less efficient. A student of Professor Schoenwaelder here has indeed experimented with this in a similar case in order to avoid difficulties with the start of a recursion. Sincerely yours Joachim Neubueser. From michel@dmi.ens.fr Tue Feb 16 10:33:35 1993 From: michel@dmi.ens.fr "Jean Michel" Date: Tue, 16 Feb 93 10:33:35 +0100 Subject: Re: apologies >> Such request as shown by the problems that you mention in your first >> letter is certainly reasonable and ought to be discussed if problems >> of the commodity of using GAP have arisen as it has been the case with >> you. I do not think, however, that such a request is a reason to use >> in a public worldwide discussion terms like you have chosen in your >> letters, like talking of "a wrong treatment of empties" or "an >> unnecessary confused answer" and the like. While we are grateful for >> each notification of a real bug, and while we appreciate every >> suggestion for the improvement of GAP, I am not willing to accept that >> users of GAP use a tone in the discussion with us like an impatient >> teacher may (but should not) use with a dumb student. >> I wish to apologize for the tone of my replies. I tend to write as I speak in the heat of the discussion, and always forget that the written word does not carry any of the verbal and gestual clues which put things in the proper context. But, please, do not think this reflect an inferior opinion of your ideas, on the contrary, I only become excited when discussing exciting topics (and never ever when I speak with someone dumb). P.S. I also think now from your reply that my question has been fully understood, so I wait eagerly for what you will do. Now another small tought about GAP to make this letter a better fit for the forum: I have had often to write code, like: 'find all rows of a matrix where an entry is the single non-zero in its column' where it would be very useful to interpret boolean true as 1 and boolean false as 0, like in C: then this particular code could be: Filtered(mat,List(Sum(mat,x->x<>0),y->y=1)); Actually implicit conversion is not necessary, it would be just as good to write Filtered(mat,List(Sum(mat,x->Int(x<>0)),y->y=1)); if Int did the conversion job. And further, a change to GAP is unnecessary, I can always define: BooltoInt:=function(b) if b then return 1 else return 0 fi;end; But, here is my problem: since GAP is yet interpreted, not compiled, calling a user-defined function like this is very costly. So what to do: - can this functionality be added to Int or any other function? - will it be possible to link to GAP functions written in C? - will there be a compiler some day? Best regards, Jean MICHEL From neubuese@samson.math.rwth-aachen.de Tue Feb 16 17:13:35 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 16 Feb 93 17:13:35 +0100 Subject: Re: your questions Dear Professor Michel, thank you for your letter and for understanding my general point on the discussion. Let me first explain the state of affairs with the new version of GAP: I have of course said for a long while that it's release is very close but this is now really the case, in fact Thomas Breuer and Frank Celler are just fixing some last known minor bugs and inconsistencies that were detected in running through all the examples in the manual. And we hope indeed that within this week GAP 3.2 will now be available through ftp. This means in particular that no major changes can be made any more for 3.2. Let me then come back to the four detailed questions at the end of your letter of yesterday. 1) adding (or in fact multiplying) the elements of a list by a number works also for the empty list and returns the empty list. As said, however, this will not be part of the description in the manual for the reasons that I explained in my last letter, namely, that this whole area of interpreting empty lists may at a later stage get revisited. 2) Thomas Breuer has changed 'TriangulizeMat' and 'BaseMat' to work also for empty lists. 3) However, 'IsVector([])' will still return 'false' for the reasons explained in Martin's letter. The problem of changing this is a nontrivial one and just changing this but then not allowing to form the scalar product of two empty lists which are recognized as legal vectors might confuse users even more. We certainly will keep this whole area in mind but I cannot promise that we will come up soon with a neat solution. Then to the questions that you asked in today's letter: 1) As you say yourself you can make a function 'IntBool' that allows you to filter out all rows of a matrix where an entry is a single nonzero in its column. But indeed, as you say, this will not be highly efficient. It will probably be much more efficient to write a function that will run through the matrix finding the columns with only one nonzero entry. The reason is that these one-line statements using 'Filtered' and 'List' are elegant but tend to use too many function calls. As you said, function calls to GAP functions are costly, but even if there was an internal function 'IntBool' doing the boolean to integer conversion, the overhead created by 'Filtered', 'List' and 'Sum' would probably outweight this advantage. 2) At present we certainly are not installing such a function 'IntBool' to the kernel and generally speaking we hesitate to extend the kernel unless a proven reasonable gain in efficiency forces us to do that. 3) The question of providing means of linking functions written in C to GAP as well as the question of a compiler for GAP have certainly been discussed here and are on the list of "dreams" for GAP. In fact with respect to a compiler even some first experiments have been started by a student. The linking of C functions has been discussed also with groups outside Aachen and if there are very definite proposals that people might have we certainly like to know them. However, both areas are nontrivial tasks and I wouldn't want to commit myself or anybody else to promise anything along these lines in the nearer future. With kind regards Joachim Neubueser From werner@pell.anu.edu.au Tue Feb 16 22:53:33 1993 From: werner@pell.anu.edu.au "Werner Nickel" Date: Tue, 16 Feb 93 22:53:33 +0100 Subject: integer vector mod integer Dear GAP forum, in writing some routines to deal with integer vectors modulo a positive integer I discovered that the operation vec mod scalar in GAP 3.1 is not possible: gap> [1,2,3,4,5,6] mod 2; Error, operations: remainder of list and integer is not defined It is possible to replace the statement above by the following gap> List( [1,2,3,4,5,6], x -> x mod 2 ); but at a cost. The following two statements were executed on a Sparc station SLC. gap> Runtime();; List( [1..60000], x -> x*2 );; Runtime()-last2;; 10167 gap> Runtime();; [1..60000]*2;; Runtime()-last2;; 1483 It would be useful to have the operation vec mod scaler available for those cases where taking the remainder makes sense. For a similar reason the operation vec mod vec for integer vectors is useful. The operation would be defined componentwise. In this way one could easily do computations in finite abelian groups. For example, adding two vectors in the group C_2 x C_4 x C_12 could be done as follows: gap> ([1,2,3] + [4,5,6]) mod [2,4,12]; [1,3,9] With kind regards, Werner Nickel. ----------------------------/|-|--|-|--|------Werner-Nickel------------------- werner@pell.anu.edu.au /_| |\ | | | Mathematics Research Section --------------------------/--|-|-\|-|_/|------Australian-National-University-- From neubuese@samson.math.rwth-aachen.de Wed Feb 17 10:06:47 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Wed, 17 Feb 93 10:06:47 +0100 Subject: Re: integer vector mod integer Lieber Herr Nickel, Thanks for the proposal. It looks nice and worthwhile and will be put on the list of quite a few that we have for future releases, but since realizing it would mean adding to the kernel of GAP it is definitely too late for 3.2. Joachim Neubueser From ffor@gauss.math.rochester.edu Wed Feb 17 19:10:34 1993 From: ffor@gauss.math.rochester.edu "Frederick Ford" Date: Wed, 17 Feb 93 19:10:34 +0100 Subject: GAP on super/parallel computers I have an opportunity to get some "free" time on either a super computer or a parallel computer. Basically, the local administrator is getting complaints from users about the lack of speed recently and I am currently the most active user on the system. He's hoping that getting me off the system will give him some breathing room. I've been running very cpu intensive GAP computations. The super computer options are: OS C compiler IBM ES-9000 AIX/370 AIX/370 C compiler IBM RS-6000 AIX AIX XL C compiler/6000 Cray-YMP UNICOS Cray standard C compiler The parallel computer is a Connection Machine (massively parallel I'm told). The OS is System V, BSD 4.3 compatible. I don't have any details on the C compiler version, but it's whatever Thinking Machines is distributing as their "standard" C compiler. I have three questions. 1) The manual indicates that GAP compiles on the IBM RS-6000. Does anyone know about any of the other platforms? 2) How much faster, generally speaking, should I expect GAP to be on these platforms? 3) Should I opt for super or parallel computing? Thanks, Frederick Ford From jcbhrb@cerf.net Thu Feb 18 00:42:25 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Thu, 18 Feb 93 00:42:25 +0100 Subject: Class Multiplication Constants and Character claculation in GAP gap-forum@samson.math.rwth-aachen.de One thing that I wish GAP could do is the direct calculation of character tables, or better yet a full set of irreducible representation matrices. I also could not find a routine for calculating class multiplication constants (or coefficients) from the conjugacy classes of group elements; this would probably be my starting point in calculating characters; oddly enough there is a routine that uses the character tables to get the class multiplication constants but that's going in the opposite direction of what I have in mind. Anyway here are my questions regarding this issue: (1) Will version 3.2 have any of the above? or should I consider writing my own routines with my very limitted expertise in gap? (2) If any other user has looked at this before, please pass along any experiences or suggestions. (3) As an interim solution, is there a way to identify a user defined group with a group which the character tables recognize: For example here's a group of order 48 which the character tables should know: a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); group4a := Group(a,b,c,z); group4a.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2]; group4p:=OperationCosetsFpGroup(group4a,Subgroup(group4a,[IdWord])); How do identify group4p to CharTable. (PS. I happen to know for this particular case but in general is this doable?) (4) When will the next version be released? Any help is greatly appreciated. Jacob Hirbawi JcbHrb@CERF.net From jcbhrb@cerf.net Thu Feb 18 07:03:22 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Thu, 18 Feb 93 07:03:22 +0100 Subject: mistake in the characters of 2.S4 ? gap-forum@samson.math.rwth-aachen.de While we're on the subject of group characters; there seems to be a mistake in the characters of 2.S4 . In case anyone is wondering this all relates to John McKay's recent post on sci.math regarding the link between the finite dicyclic groups <2,3,3>=SL(2,3), <2,3,4>=2.S4, <2,3,5>=2.A5 and the exceptional Lie algebras E6,E7,E8. gap> CharTable("2.S4"); .... irreducibles := [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], [ 4, -4, 0, 0, 0, 0, 1, -1 ], [ 2, -2, 0, 0, E(8)+E(8)^3, -E(8)-E(8)^3, -1, 1 ], [ 2, -2, 0, 0, -E(8)-E(8)^3, E(8)+E(8)^3, -1, 1 ], [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], .... I could not duplicate John's constructions with the above characters but using the table below everything seems to fit nicely: [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], [ 4, -4, 0, 0, 0, 0, 1, -1 ], [ 2, -2, 0, 0, E(8)^3+E(8)^5, -E(8)^3-E(8)^5, -1, 1 ], [ 2, -2, 0, 0, -E(8)^3-E(8)^5, E(8)^3+E(8)^5, -1, 1 ], [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], both tables pass the TestCharacterTable tests! Jacob Hirbawi JcbHrb@CERF.net From neubuese@samson.math.rwth-aachen.de Thu Feb 18 10:03:45 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 18 Feb 93 10:03:45 +0100 Subject: Re: GAP on super/parallel computers Frederick Ford asks about GAP on super/parallel computers. I am sorry that from Aachen at present we cannot give much advice on his questions, we have not tried any of the systems that are mentioned here. I think GAP is used on an RS-6000 e.g. at Essen , perhaps Gerhard Schneider (formerly Essen, now Karlsruhe) can give advice on IBMs generally. I seem to remember that the question of GAP on a supercomputer has been mentioned in the connection of measuring GAPstones, but I have not kept that correspondence. Perhaps somebody from the GAP-forum has some experience. Also Martin Schoenert may have some information from private correspondence, but he will return from holidays at the beginning of March only. Generally I would not expect too much gain from a parallel machine since there is nothing in GAP specially supporting parallel computing, but this is pure (maybe poor) guessing. I you dare to try, we would be interested to hear of the outcome. Joachim Neubueser From sam@ernie.math.rwth-aachen.de Thu Feb 18 13:41:57 1993 From: sam@ernie.math.rwth-aachen.de "Thomas Breuer" Date: Thu, 18 Feb 93 13:41:57 +0100 Subject: Dear Mrs. and Mr. Forum, in his message of 18 Feb 93 Jacob Hirbawi asks some questions concerning character tables. > One thing that I wish GAP could do is the direct calculation of character > tables, or better yet a full set of irreducible representation matrices. In GAP-3.1 both is possible for finite polycyclic groups $G$ with the property that there is an abelian normal subgroup $N$ of $G$ such that the factor group $G/N$ is supersolvable. The GAP functions in question are 'MatRepresentationsPGroup' and 'CharTablePGroup'. The algorithm used is described in U. Baum. Existenz und effiziente Konstruktion schneller Fouriertransformationen "uberaufl"osbarer Gruppen. Dissertation, Rheinische Friedrich Wilhelm Universit"at Bonn, 1991. (An English version of this was also published in 1992, but at the moment I don't find where.) Jacob Hirbawi continues: > I also could not find a routine for calculating class multiplication > constants (or coefficients) from the conjugacy classes of group elements; > this would probably be my starting point in calculating characters; In GAP-3.2 there will be an implementation of the so-called Dixon-Schneider method for the computation of character tables of finite groups. This algorithm in fact does compute class multiplication constants, and from that the irreducible characters. Alexander Hulpke did this implementation, and he could compute the tables of some large maximal subgroups of sporadic simple groups using this program, e.g., the 8th maximal subgroup of the Conway group Co1, with structure $2^{2+12}:(A_8 x S_3)$. To compute the character table of a given group in GAP-3.2 using the Dixon-Schneider method, one will just call 'CharTable( )'. Also it will be possible to combine this method with character theoretical tools that were available already in GAP-3.1. The algorithm is described in J.D. Dixon. High speed computations of group characters. Num. Math. 10, 446-450 and G.J.A. Schneider. Dixon's Character Table Algorithm Revisited. J. Symbolic Computation (1990) 9, 601-606. As for computing the representations of arbitrary groups (i.e., groups that are not of the type required for 'CharTablePGroup'), we have no algorithm up to now. Jacob Hirbawi continues: > oddly enough there is a routine that uses the character tables to get the > class multiplication constants but that's going in the opposite direction > of what I have in mind. Often it is useful to compute class multiplication constants from character tables, e.g., if the group is too large for computations. First, the question whether there is a class C in a group G such that G = CC can be answered by computing class multiplication constants; for the 26 sporadic simple groups the answer is "yes", this was checked from the character tables in J. Neub"user, H. Pahlings, E.Cleuvers. Each sporadic finasig G has a class C such that CC = G. Abstracts AMS, 6 (34), 1984. Second, it is often possible to prove that a group is a Galois group over the Rationals using a theorem of Belyi, Fried, Matzat, and Thompson. One part is the inspection of class multiplication coefficient, the other part requires inspection of maximal subgroups of the given group. Such calculations can be found in H. Pahlings, Some Sporadic Groups as Galois Groups. Rend. Sem. Mat. Univ. Padova, Vol. 79 (1988) and H. Pahlings, Some Sporadic Groups as Galois Groups II. Rend. Sem. Mat. Univ. Padova, Vol. 82 (1989). Jacob Hirbawi continues: > Anyway here are my questions regarding this issue: > > (1) Will version 3.2 have any of the above? or should I consider > writing my own routines with my very limitted expertise in > gap? > > (2) If any other user has looked at this before, please pass along > any experiences or suggestions. > > (3) As an interim solution, is there a way to identify a user defined > group with a group which the character tables recognize: > > For example here's a group of order 48 which the character tables > should know: > > a := AbstractGenerator("a"); > b := AbstractGenerator("b"); > c := AbstractGenerator("c"); > z := AbstractGenerator("z"); > group4a := Group(a,b,c,z); > group4a.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2]; > group4p:=OperationCosetsFpGroup(group4a,Subgroup(group4a,[IdWord])); > > How do identify group4p to CharTable. (PS. I happen to know for this > particular case but in general is this doable?) > > (4) When will the next version be released? As already said, the answer to the first part of (1) is "yes". Question (3) addresses a more general problem: In GAP-3.1 there was no very close connection between character tables and groups, dealing with character tables was mainly talking about groups, not working with groups. But of course one wants to deal with both the group and its table in many situations. When the table was computed from the group in GAP, there is no problem, since the ordering of conjugacy classes in table and group are the same. But if one has a group, and wants to identify its classes with the columns of a given library table (e.g., one contained in the ATLAS of finite groups), this is not supported by GAP. For some series of groups there are generic character tables in GAP, and the parameters allow to identify classes and characters. In the future these parameters will be added to the library tables belonging to such a series. The answer to (4) is "tomorrow". The second message of Jacob Hirbawi tells about a problem with library tables. He writes > While we're on the subject of group characters; there seems to be > a mistake in the characters of 2.S4 . In case anyone is wondering > this all relates to John McKay's recent post on sci.math regarding > the link between the finite dicyclic groups <2,3,3>=SL(2,3), > <2,3,4>=2.S4, <2,3,5>=2.A5 and the exceptional Lie algebras E6,E7,E8. > > gap> CharTable("2.S4"); > .... > irreducibles := > [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], > [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], > [ 4, -4, 0, 0, 0, 0, 1, -1 ], > [ 2, -2, 0, 0, E(8)+E(8)^3, -E(8)-E(8)^3, -1, 1 ], > [ 2, -2, 0, 0, -E(8)-E(8)^3, E(8)+E(8)^3, -1, 1 ], > [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], > .... > > I could not duplicate John's constructions with the above characters > but using the table below everything seems to fit nicely: > > [ [ 1, 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, 1, -1, -1, -1, 1, 1 ], > [ 2, 2, 2, 0, 0, 0, -1, -1 ], [ 3, 3, -1, 1, -1, -1, 0, 0 ], > [ 4, -4, 0, 0, 0, 0, 1, -1 ], > [ 2, -2, 0, 0, E(8)^3+E(8)^5, -E(8)^3-E(8)^5, -1, 1 ], > [ 2, -2, 0, 0, -E(8)^3-E(8)^5, E(8)^3+E(8)^5, -1, 1 ], > [ 3, 3, -1, -1, 1, 1, 0, 0 ] ], > > both tables pass the TestCharacterTable tests! Both lists of irreducible characters belong to character tables of groups of structure 2.S4, so orthogonality relations are satisfied. The table with name "2.S4" in the table library is one of them, namely the table of the involution centralizer in the Mathieu group M11. The other table is that of an isoclinic group, which can be got in GAP using the following commmands. gap> t:= CharTable( "2.S4" );; gap> DisplayCharTable( t ); 2.S4 2 4 4 3 2 3 3 1 1 3 1 1 . . . . 1 1 1a 2a 4a 2b 8a 8b 3a 6a 2P 1a 1a 2a 1a 4a 4a 3a 3a 3P 1a 2a 4a 2b 8a 8b 1a 2a X.1 1 1 1 1 1 1 1 1 X.2 1 1 1 -1 -1 -1 1 1 X.3 2 2 2 . . . -1 -1 X.4 3 3 -1 1 -1 -1 . . X.5 4 -4 . . . . 1 -1 X.6 2 -2 . . A -A -1 1 X.7 2 -2 . . -A A -1 1 X.8 3 3 -1 -1 1 1 . . A = E(8)+E(8)^3 = ER(-2) = i2 gap> iso:= CharTableIsoclinic( t );; gap> DisplayCharTable( iso ); Isoclinic(2.S4) 2 4 4 3 2 3 3 1 1 3 1 1 . . . . 1 1 1a 2a 4a 4b 8a 8b 3a 6a 2P 1a 1a 2a 2a 4a 4a 3a 3a 3P 1a 2a 4a 4b 8b 8a 1a 2a X.1 1 1 1 1 1 1 1 1 X.2 1 1 1 -1 -1 -1 1 1 X.3 2 2 2 . . . -1 -1 X.4 3 3 -1 1 -1 -1 . . X.5 4 -4 . . . . 1 -1 X.6 2 -2 . . A -A -1 1 X.7 2 -2 . . -A A -1 1 X.8 3 3 -1 -1 1 1 . . A = -E(8)+E(8)^3 = -ER(2) = -r2 At the moment, the function 'CharTableIsoclinic' does this job only for tables with underlying group of structure 2.G.2, as in this example. Note that not only the characters may be different but also the power maps. Clearly it is a problem to access tables via names that do not uniquely determine the group but this is the most convenient way to deal with the tables that occur in the ATLAS of finite groups which serves as standard for the table names. Best wishes Thomas Breuer (sam@ernie.math.rwth-aachen.de) From neubuese@samson.math.rwth-aachen.de Thu Feb 18 14:42:51 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 18 Feb 93 14:42:51 +0100 Subject: Re: GAP for MAC, new version ? On Feb. 13, Boris Borcic asked: > I think I recall a new version of GAP for the Macintosh > was promised maybe mid-december for maybe mid-january > by the authors of the original port. > > Is it still in the works ? I am afraid a lot of promises have been made about the new version of GAP coming out soon, but that they have not been fulfilled is our fault, not that of the group of people working with Professor Mendelsohn in the University of Manitoba who kindly undertook the port to MACs. However after these days really the new version is being released, I hope that we will get again a port to the MAC family through the help of the same group of people. Joachim Neubueser From sl25@cus.cam.ac.uk Thu Feb 18 17:30:39 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Thu, 18 Feb 93 17:30:39 +0100 Subject: Re: GAP on super/parallel computers Everything I am about to say is guesswork, and I would be delighted to be proved wrong: GAP is very unlikely to benefit from a massively parallel system such as a connection machine without considerable help. In principle, some (though not very many) of the array operations involved in large list or permutation calculations could be speeded up, but they would have to be VERY large before the gain exceeded the overhead of distributing the data to the various machines. Also the compiler is unlikely to spot any useful parallelisations in the GAP kernel. It will be looking for floating point array calculations and the like. Super-computers are also usually optimised mainly for floating point array calculations, but will probably still give you some gain on large list, permutation and vector operations. They also usually have basic scalar processors comparable to the fastest workstations, and lots of real memory, both of which may help you. Of the options you suggest, I'd recommend the RS/6000, on the grounds of ease of porting and ease of use. The ES/9000 might be a few times faster as would the Cray, but you'd really be wasting their capabilities, and you'd probably have to do some work on the porting. I don't know what machine you're working on, but a Sun Sparcstation 1+ scores about 15000 GAPstones (see the archives of this list for lots more ratings) and an RS6000 (possibly not the model you have in mind) scores 41000. I would guess (pure stab in the dark) at about 100000 for the ES/9000, and perhaps 200000 on the Cray, but I could be miles out. Have you made sure that you can't speed up your programs by improving algorithms, or even by recoding key steps in C? This is usually the best choice where it's possible. Steve From dawn@math.wayne.edu Thu Feb 18 22:09:52 1993 From: dawn@math.wayne.edu "Dawn Endico" Date: Thu, 18 Feb 93 22:09:52 +0100 Subject: Re: GAP on super/parallel computers >I don't know what machine you're working on, but a Sun Sparcstation >1+ scores about 15000 GAPstones (see the archives of this list for >lots more ratings) and an RS6000 (possibly not the model you have in Archives?!? That reminds me that I've been meaning to ask whether anyone has gap-forum archives available on a gohper server. FTP? -- Dawn Endico dawn@math.wayne.edu From fceller@bert.math.rwth-aachen.de Fri Feb 19 20:11:14 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Fri, 19 Feb 93 20:11:14 +0100 Subject: GAP 3.2 Dear Forum, eventually we release GAP 3.2. Please allow a few days until the FTP servers outside Aachen mentioned below will provide the new files. The files "gapexe.su3", "gapexe.st" and "gapexe.next" are not yet available but will be added as soon as possible. Have fun with GAP Thomas Breuer, Frank Celler and Alexander Hulpke ----------------------------------------------------------------------------- Introduction ============ GAP is a system for computational discrete algebra, which we have developed with particular emphasis on computational group theory, but which has already proved useful also in other areas. The name GAP is an acronym for *Groups, Algorithms, and Programming*. This (long) document announces the availability of GAP version 3 release 2, GAP 3.2 for short. It is an *advertisement* for GAP, but not a *commercial*, since we give GAP away for free. This document begins with the section "Announcement", which contains the announcement proper. The next section "Analyzing Rubik's Cube with GAP" contains an extensive example. This example is followed by a general discussion of GAP's capabilities in the section "An Overview of GAP". The section "What's New in 3.2" tells you about the new features in GAP 3.2. The next sections "How to get GAP" and "How to install GAP" describe how you can get GAP running on your computer. Then we tell you about our plans for the future in the section "The Future of GAP". The final section "The GAP Forum" introduces the GAP forum, where interested users can discuss GAP related topics by e-mail messages. Announcement ============ Il est trop tard, maintenant, il sera toujours trop tard. Heureusement! (A. Camus, La chute) ######## Lehrstuhl D fuer Mathematik ### #### RWTH Aachen ## ## ## # ####### ######### ## # ## ## # ## ## # # ## # ## #### ## ## # # ## ##### ### ## ## ## ## ######### # ######### ####### # # ## Version 3 # ### Release 2 # ## # 12 Feb 93 # ## # ## # Alice Niemeyer, Werner Nickel, Martin Schoenert ## # Johannes Meier, Alex Wegner, Thomas Bischops ## # Frank Celler, Juergen Mnich, Udo Polis ### ## Thomas Breuer, Goetz Pfeiffer, Hans U. Besche ###### Volkmar Felsch, Heiko Theissen, Alexander Hulpke Ansgar Kaup, Akos Seress Lehrstuhl D f"ur Mathematik, RWTH Aachen, announces the availability of GAP version 3 release 2, or GAP 3.2 for short. This is the first publicly available release of GAP since version 3.1, which was distributed since April 1992. Analyzing Rubik's Cube with GAP =============================== Ideal Toy Company stated on the package of the original Rubik cube that there were more than three billion possible states the cube could attain. It's analogous to Mac Donald's proudly announcing that they've sold more than 120 hamburgers. (J. A. Paulos, Innumeracy) To show you what GAP can do a short example is probably best. If you are not interested in this example skip to the section "An Overview of GAP". For the example we consider the group of transformations of Rubik's magic cube. If we number the faces of this cube as follows +--------------+ | 1 2 3 | | 4 top 5 | | 6 7 8 | +--------------+--------------+--------------+--------------+ | 9 10 11 | 17 18 19 | 25 26 27 | 33 34 35 | | 12 left 13 | 20 front 21 | 28 right 29 | 36 rear 37 | | 14 15 16 | 22 23 24 | 30 31 32 | 38 39 40 | +--------------+--------------+--------------+--------------+ | 41 42 43 | | 44 bottom 45 | | 46 47 48 | +--------------+ then the group is generated by the following generators, corresponding to the six faces of the cube (the two semicolons tell GAP not to print the result, which is identical to the input here). gap> cube := Group( > ( 1, 3, 8, 6)( 2, 5, 7, 4)( 9,33,25,17)(10,34,26,18)(11,35,27,19), > ( 9,11,16,14)(10,13,15,12)( 1,17,41,40)( 4,20,44,37)( 6,22,46,35), > (17,19,24,22)(18,21,23,20)( 6,25,43,16)( 7,28,42,13)( 8,30,41,11), > (25,27,32,30)(26,29,31,28)( 3,38,43,19)( 5,36,45,21)( 8,33,48,24), > (33,35,40,38)(34,37,39,36)( 3, 9,46,32)( 2,12,47,29)( 1,14,48,27), > (41,43,48,46)(42,45,47,44)(14,22,30,38)(15,23,31,39)(16,24,32,40) > );; First we want to know the size of this group. gap> Size( cube ); 43252003274489856000 Since this is a little bit unhandy, let us factorize this number. gap> Collected( Factors( last ) ); [ [ 2, 27 ], [ 3, 14 ], [ 5, 3 ], [ 7, 2 ], [ 11, 1 ] ] (The result tells us that the size is 2^27 3^14 5^3 7^2 11.) Next let us investigate the operation of the group on the 48 points. gap> orbits := Orbits( cube, [1..48] ); [ [ 1, 3, 17, 14, 8, 38, 9, 41, 19, 48, 22, 6, 30, 33, 43, 11, 46, 40, 24, 27, 25, 35, 16, 32 ], [ 2, 5, 12, 7, 36, 10, 47, 4, 28, 45, 34, 13, 29, 44, 20, 42, 26, 21, 37, 15, 31, 18, 23, 39 ] ] The first orbit contains the points at the corners, the second those at the edges; clearly the group cannot move a point at a corner onto a point at an edge. So to investigate the cube group we first investigate the operation on the corner points. Note that the constructed group that describes this operation will operate on the set [1..24], not on the original set [1,3,17,14,8,38,9,41,19,48,22,6,30,33,43,11,46,40,24,27,25,35,16,32]. gap> cube1 := Operation( cube, orbits[1] ); Group( ( 1, 2, 5,12)( 3, 7,14,21)( 9,16,22,20), ( 1, 3, 8,18)( 4, 7,16,23)(11,17,22,12), ( 3, 9,19,11)( 5,13, 8,16)(12,21,15,23), ( 2, 6,15, 9)( 5,14,10,19)(13,21,20,24), ( 1, 4,10,20)( 2, 7,17,24)( 6,14,22,18), ( 4,11,13, 6)( 8,15,10,17)(18,23,19,24) ) gap> Size( cube1 ); 88179840 Now this group obviously operates transitively, but let us test whether it is also primitive. gap> corners := Blocks( cube1, [1..24] ); [ [ 1, 7, 22 ], [ 2, 14, 20 ], [ 3, 12, 16 ], [ 4, 17, 18 ], [ 5, 9, 21 ], [ 6, 10, 24 ], [ 8, 11, 23 ], [ 13, 15, 19 ] ] Those eight blocks correspond to the eight corners of the cube; on the one hand the group permutes those and on the other hand it permutes the three points at each corner cyclically. So the obvious thing to do is to investigate the operation of the group on the eight corners. gap> cube1b := Operation( cube1, corners, OnSets ); Group( (1,2,5,3), (1,3,7,4), (3,5,8,7), (2,6,8,5), (1,4,6,2), (4,7,8,6) ) gap> Size( cube1b ); 40320 Now a permutation group of degree 8 that has order 40320 must be the full symmetric group S(8) on eight points. The next thing then is to investigate the kernel of this operation on blocks, i.e., the subgroup of 'cube1' of those elements that fix the blocks setwise. gap> blockhom1 := OperationHomomorphism( cube1, cube1b );; gap> Factors( Size( Kernel( blockhom1 ) ) ); [ 3, 3, 3, 3, 3, 3, 3 ] gap> IsElementaryAbelian( Kernel( blockhom1 ) ); true We can show that the product of this elementary abelian group 3^7 with the S(8) is semidirect by finding a complement, i.e., a subgroup that has trivial intersection with the kernel and that generates 'cube1' together with the kernel. gap> cmpl1 := Stabilizer( cube1, [1,2,3,4,5,6,8,13], OnSets );; gap> Size( cmpl1 ); 40320 gap> Size( Intersection( cmpl1, Kernel( blockhom1 ) ) ); 1 gap> Closure( cmpl1, Kernel( blockhom1 ) ) = cube1; true There is even a more elegant way to show that 'cmpl1' is a complement. gap> IsIsomorphism( OperationHomomorphism( cmpl1, cube1b ) ); true Of course, theoretically it is clear that 'cmpl1' must indeed be a complement. In fact we know that 'cube1' is a subgroup of index 3 in the wreath product of a cyclic 3 with S(8). This missing index 3 tells us that we do not have total freedom in turning the corners. The following tests show that whenever we turn one corner clockwise we must turn another corner counterclockwise. gap> (1,7,22) in cube1; false gap> (1,7,22)(2,20,14) in cube1; true More or less the same things happen when we consider the operation of the cube group on the edges. gap> cube2 := Operation( cube, orbits[2] );; gap> Size( cube2 ); 980995276800 gap> edges := Blocks( cube2, [1..24] ); [ [ 1, 11 ], [ 2, 17 ], [ 3, 19 ], [ 4, 22 ], [ 5, 13 ], [ 6, 8 ], [ 7, 24 ], [ 9, 18 ], [ 10, 21 ], [ 12, 15 ], [ 14, 20 ], [ 16, 23 ] ] gap> cube2b := Operation( cube2, edges, OnSets );; gap> Size( cube2b ); 479001600 gap> blockhom2 := OperationHomomorphism( cube2, cube2b );; gap> Factors( Size( Kernel( blockhom2 ) ) ); [ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2 ] gap> IsElementaryAbelian( Kernel( blockhom2 ) ); true gap> cmpl2 := Stabilizer(cube2,[1,2,3,4,5,6,7,9,10,12,14,16],OnSets);; gap> IsIsomorphism( OperationHomomorphism( cmpl2, cube2b ) ); true This time we get a semidirect product of a 2^11 with an S(12), namely a subgroup of index 2 of the wreath product of a cyclic 2 with S(12). Here the missing index 2 tells us again that we do not have total freedom in turning the edges. The following tests show that whenever we flip one edge we must also flip another edge. gap> (1,11) in cube2; false gap> (1,11)(2,17) in cube2; true Since 'cube1' and 'cube2' are the groups describing the actions on the two orbits of 'cube', it is clear that 'cube' is a subdirect product of those groups, i.e., a subgroup of the direct product. Comparing the sizes of 'cube1', 'cube2', and 'cube' we see that 'cube' must be a subgroup of index 2 in the direct product of those two groups. gap> Size( cube ); 43252003274489856000 gap> Size( cube1 ) * Size( cube2 ); 86504006548979712000 This final missing index 2 tells us that we cannot operate on corners and edges totally independently. The following tests show that whenever we exchange a pair of corners we must also exchange a pair of edges (and vice versa). gap> (17,19)(11,8)(6,25) in cube; false gap> (7,28)(18,21) in cube; false gap> (17,19)(11,8)(6,25)(7,28)(18,21) in cube; true Finally let us compute the centre of the cube group, i.e., the subgroup of those operations that can be performed either before or after any other operation with the same result. gap> Centre( cube ); Subgroup( cube, [ ( 2,34)( 4,10)( 5,26)( 7,18)(12,37)(13,20) (15,44)(21,28)(23,42)(29,36)(31,45)(39,47) ] ) We see that the centre contains one nontrivial element, namely the operation that flips all 12 edges simultaneously. This concludes our example. Of course, GAP can do much more, and the next section gives an overview of its capabilities, but demonstrating them all would take too much room. An Overview of GAP ================== Though this be madness, yet there is method in't. (W. Shakespeare, Hamlet) GAP consists of several parts: the kernel, the library of functions, the library of groups and related data, and the documentation. The *kernel* implements an automatic memory management, a PASCAL-like programming language, also called GAP, with special datatypes for computations in group theory, and an interactive programming environment to run programs written in the GAP programming language. The automatic *memory management* allows programmers to concentrate on implementing the algorithm without needing to care about allocation and deallocation of memory. It includes a garbage collection that automatically throws away objects that are no longer accessible. The GAP programming language supports a number of datatypes for elements of fields. *Integers* can be arbitrarily large, and are implemented in such a way that operations with small integers are reasonably fast. Building on this large-integer arithmetic GAP supports *rationals* and elements from *cyclotomic fields*. Also GAP allows one to work with elements from *finite fields* of size (at present) at most 2^16. The special datatypes of group elements are *permutations*, *matrices* over the rationals, cyclotomic fields, and finite fields, *words in abstract generators*, and *words in solvable groups*. GAP also contains a very flexible *list* datatype. A list is simply a collection of objects that allows you to access the components using an integer position. Lists grow automatically when you add new elements to them. Lists are used to represent sets, vectors, and matrices. A *set* is represented by a sorted list without duplicates. A list whose elements all lie in a common field is a *vector*. A list of vectors of the same length over a common field is a *matrix*. Since sets, vectors, and matrices are lists, all list operations and functions are applicable. You can, for example, find a certain element in a vector with the general function 'Position'. There are also *ranges*, i.e., lists of consecutive integers, and *boolean lists*, i.e., lists containing only 'true' and 'false'. Vectors, ranges, and boolean lists have special internal representations to ensure efficient operations and memory usage. For example, a boolean list requires only one bit per element. *Records* in GAP are similar to lists, except that accessing the components of a record is done using a name instead of an index. Records are used to collect objects of different types, while lists usually only contain elements of one type. Records are for example used to represent groups and other domains; there is *no* group datatype in the GAP language . Because of this all information that GAP knows about a group is also accessible to you by simply investigating the record. The control structures of GAP are PASCAL-like. GAP has *if* statements, *while*, *repeat*, and *for* loops. The for loop is a little bit uncommon in that it always loops over the elements of a list. The usual semantics can be obtained by looping over the elements of a range. Using those building blocks you can write *functions*. Functions can be recursive, and are first class objects in the sense that you can collect functions in lists, pass them as arguments to other functions and also return them. It is important to note that GAP has dynamic typing instead of static typing. That means that the datatype is a property of the object, not of the variable. This allows you to write general functions. For example the generic function that computes an orbit can be used to compute the orbit of an integer under a permutation group, the orbit of a vector under a matrix group, the conjugacy class of a group element, and many more. The kernel also implements an *interactive environment* that allows you to use GAP. This environment supports debugging; in case of an error a break loop is entered in which you can investigate the problem, and maybe correct it and continue. You also have online access to the manual, though sections that contain larger formulas do not look nice on the screen. The *library of functions*, simply called library in the following, contains implementations of various group theoretical algorithms written in the GAP language. Because all the group theoretical functions are in this library it is easy for you to look at them to find out how they work, and change them if they do almost, but not quite, what you want. The whole library is centered around the concept of domains and categories. A *domain* is a structured set, e.g., a group is a domain as is the ring of Gaussian integers. Each domain in GAP belongs to one or more *categories*, which are simply sets of domains, e.g., the set of all groups forms a category. The categories in which a domain lies determine the functions that are applicable to this domain and its elements. To each domain belongs a set of functions, in a so called operations record, that are called by dispatchers like 'Size'. For example, for a permutation group , '.operations.Size' is a function implementing the Schreier Sims algorithm. Thus if you have any domain , simply calling 'Size( )' will return the size of the domain , computed by an appropriate function. Domains *inherit* such functions from their category, unless they redefine them. For example, for a permutation group , the derived subgroup will be computed by the generic group function, which computes the normal closure of the subgroup generated by the commutators of the generators. Of course the most important category is the category of *groups*. There are about 100 functions applicable to groups. These include general functions such as 'Centralizer' and 'SylowSubgroup', functions that compute series of subgroups such as 'LowerCentralSeries', a function that computes the whole lattice of subgroups, functions that test predicates such as 'IsSimple', functions that are related to the operations of groups such as 'Stabilizer', and many more. Most of these functions are applicable to all groups, e.g., permutation groups, finite polycyclic groups, factor groups, direct products of arbitrary groups, and even new types of groups that you create by simply specifying how the elements are multiplied and inverted (actually it is not quite so simple, but you can do it). Where the general functions that are applicable to all groups are not efficient enough, we have tried to overlay them by more efficient functions for special types of groups. The prime example is the category of *permutation groups*, which overlays 'Size', 'Elements', 'Centralizer', 'Normalizer', 'SylowSubgroup', and a few more functions by functions that employ stabilizer chains and backtracking algorithms. Also many of the functions that deal with operations of groups are overlayed for permutation groups for the operation of a permutation group on integers or lists of integers. Special functions for *finitely presented groups* include functions to find the index of a subgroup via a Todd-Coxeter coset enumeration, to compute the abelian invariants of the commutator factor group, to intersect two subgroups, to find the normalizer of a subgroup, to find all subgroups of small index, and to compute and simplify presentations for subgroups. Of course it is possible to go to a permutation group operating on the cosets of a subgroup and then to work with this permutation group. For *finite polycyclic groups* a special kind of presentation corresponding to a composition series is used. Such a presentation implies a canonical form for the elements and thus allows efficient operations with the elements of such a group. This presentation is used to make functions such as 'Centralizer', 'Normalizer', 'Intersection', and 'ConjugacyClasses' very efficient. GAP's capabilities for finite polycyclic groups exceed those of the computer system SOGOS (which was developed at Lehrstuhl D f"ur Mathematik for the last decade). There is also support for *mappings* and *homomorphisms*. Since they play such a ubiquitous role in mathematics, it is only natural that they should also play an important role in a system like GAP. Mappings and homomorphisms are objects in their own right in GAP. You can apply a mapping to an element of its source, multiply mappings (provided that the range of the first is a subset of the source of the second), invert mappings (even if what you get is a multi-valued mapping), and perform a few more operations. Important examples are the 'NaturalHomomorphism' onto a factor group, 'OperationsHomomorphism' mapping a group that operates on a set of elements into the symmetric group on [1..], 'Embeddings' into products of groups, 'Projections' from products of groups onto the components, and the general 'GroupHomomorphismByImages' for which you only specify the images of a set of generators. The library contains a package for handling character tables of finite groups. This includes almost all possibilities of the computer system CAS (which was developed at Lehrstuhl D f"ur Mathematik in the last decade), and many new functions. You can compute character tables of groups, or construct character tables using other tables, or do some calculations within known character tables. You can, for example, compute a list of candidates for permutation characters. Of course there are many character tables (at the moment more than 650 ordinary tables) in the data library, including all those in the ATLAS of finite groups. For large integers we now also have a package for *elementary number theory*. There are functions in this package to test primality, factor integers of reasonable size, compute the size phi() of the prime residue group modulo an integer , compute roots modulo an integer , etc. Also based on this there is a package to do calculations in the ring of Gaussian integers. The library also includes a package for *combinatorics*. This contains functions to find all selections of various flavours of the elements of a set, e.g., 'Combinations' and 'Tuples', or the number of such selections, e.g., 'Binomial'. Other functions are related to partitions of sets or integers, e.g., 'PartitionsSet' and 'RestrictedPartitions', or the number of such, e.g., 'NrPartitions' and 'Bell'. It also contains some miscellaneous functions such as 'Fibonacci' and 'Bernoulli'. The *data library* at present contains the primitive permutation groups of degree up to 50 from C. Sims, the 2-groups of size dividing 256 from E. O'Brien and M. F. Newman, the 3-groups of size dividing 729 from E. O'Brien and C. Rhodes, the solvable groups of size up to 100 from M. Hall, J. K. Senior, R. Laue, and J. Neub"user, a library of character tables including all of the ATLAS, and a library of tables of marks for various groups. We plan to extend the data library with more data in the future. Together with GAP 3.2 we now distribute several *share library packages*. Such packages have been contributed by other authors, but the copyright remains with the author. Currently there are three packages in the share library. The *ANU PQ* package, written by E. O'Brien, consists of a C program implementing a

-quotient and a

-group generation algorithm and functions to interface this program with GAP (or Cayley). The *NQ* package, written by W. Nickel, consists of a C program implementing an algorithm to compute the largest nilpotent quotient of a finitely presented group and a function to call this program from GAP. The *Weyl* package, written by M. Geck, contains functions to compute with finite Weyl groups, associated (Iwahori-) Hecke algebras, and their representations. What's New in 3.2 ================= It is now possible to extract several elements from a list with a construct similar to the one used to extract single elements. This also works recursively, so that it is for example possible to extract a submatrix of a matrix. It is also possible to assign several elements to a list at once. Permutations can now operate on more than 65536 points. Ranges can now also have increments other than 1, i.e., a range is now a dense list of integers such that the difference between any two consecutive elements is a nonzero constant. Strings are now also lists, namely lists of characters, which are a new builtin datatype. This makes functions easier to write that deal extensively with strings, such as 'DisplayCharTable'. GAP now supports *univariate polynomials* over arbitrary coefficient rings. Since the coefficient ring may itself be a polynomial ring it is possible to create multivariate polynomial rings, though this is not very efficient. Polynomials are implemented in the GAP programming language, but there are supporting kernel functions to improve efficiency. Previously the entries of a matrix had to be among the built-in datatypes, i.e., rationals, cyclotomics, and finite field elements. This restriction has been removed, so that it is now possible for example to compute with matrices whose entries are polynomials. There is now an implementation of the Dixon-Schneider algorithm, which computes the character table of an arbitrary group. For permutation groups there are new functions to test if a permutation group is solvable, and if so to find a power-commutator presentation. Also there is a new function to compute the composition series of a permutation group. The functions to compute presentations for subgroups of finitely presented groups and to simplify them are new. There are new functions that work with table of marks, which give a compact description of the subgroup lattice of a group. For example there is a function that computes the value of the Moebius function for the subgroup lattice of a group with a given table of marks. E. O'Brien and C. Rhodes provided a library of 3-groups of size dividing 729. The character table library has been extended by about 60 new ordinary tables and about 200 new modular tables. There is also a data library that contains table of marks for various groups, e.g., McL. The share library packages *ANU PQ*, *NQ*, and *Weyl* mentioned in the previous section are also new. How to get GAP ============== Ceterum censeo: Nobody has ever paid a licence fee for using a proof that shows Sylow's subgroups to exist. Nobody should ever pay a licence fee for using a program that computes Sylow's subgroups. (J. Neub"user) GAP is distributed *free of charge*. You can obtain it via 'ftp' or electronic mail and give it away to your colleagues. GAP is *not* in the public domain, however. In particular you are not allowed to incorporate GAP or parts thereof into a commercial product. If you get GAP, we would appreciate it if you could notify us, e.g., by sending a short e-mail message to 'gap@samson.math.rwth-aachen.de', containing your full name and address, so that we have a rough idea of the number of users. We also hope that this number will be large enough to convince various agencies that GAP is a project worthy of (financial) support. If you publish some result that was partly obtained using GAP, we would appreciate it if you would cite GAP, just as you would cite another paper that you used. Again we would appreciate if you could inform us about such a paper. We distribute the *full source* for everything, the C code for the kernel, the GAP code for the library, and the LaTeX code for the manual, which has at present about 800 pages. So it should be no problem to get GAP, even if you have a rather uncommon system. Of course, ports to non UNIX systems may require some work. We already have ports for IBM PC compatibles with an Intel 80386 or 80486 and for the Atari ST. We also hope to provide a port of GAP 3.2 to the Apple Macintosh in the near future (there is already a port of GAP 3.1). Note that about 4 MByte of main memory and a harddisk are required to run GAP. GAP 3.2 can be obtained by anonymous *ftp* from the following servers. 'samson.math.rwth-aachen.de': Lehrstuhl D fur Mathematik, RWTH Aachen, Germany (137.226.152.6). 'dimacs.rutgers.edu': DIMACS, Rutgers, New Brunswick, New Jersey (128.6.75.16). 'math.ucla.edu': Math. Dept., Univ. of California at Los Angeles (128.97.4.254). 'wuarchive.wustl.edu': Mathematics Archives, Univ. of Tennessee (128.252.135.4, directory '/edu/math/source.code/group.theory/gap'). 'pell.anu.edu.au': Math. Research Section, Australian National Univ. (150.203.15.5). 'ftp' to the server *closest* to you, login as user 'ftp' and give your full e-mail address as password. GAP is in the directory 'pub/gap'. Remember when you transmit the files to set the file transfer type to *binary image*, otherwise you will only receive unusable garbage. Those servers will always have the latest version of GAP available. GAP can also be obtained via *electronic mail*. To get one of the files mentioned below send a message to 'listserv@samson.math.rwth-aachen.de' containing a line 'get GAP ', e.g., 'get GAP src3r2.tar.Z'. 'listserv' will reply by sending you the file as e-mail message. Because most files are large binary files they will be uuencoded and split into several parts, each at most 64 kBytes large. You can concatenate the parts by hand, removing the mail header, and then use 'uudecode' to decode them. We suggest however that you also get 'uud.c', which skips the mail headers automatically and is also able to fix up transmission errors caused by 'EBCDIC' machines. You can also get single parts of a file by sending 'get GAP '. For users in the United Kingdom with only Janet access, neither 'ftp' nor the mail server will work (please do *not* try to use the mail server). Please contact Derek Holt (e-mail address 'dfh@maths.warwick.ac.uk'). He has kindly offered us to distribute GAP in the United Kingdom. The 'ftp' directory and the 'listserv' archive contain the following files. Please check first which files you need, to avoid transferring those that you don't need. 'README': the file you are currently reading. GAP version 3 release 2 itself comes in several files. You do not need all of those files. All files are 'compress'-ed 'tar' archives. 'src3r2.tar.Z': the *source code* for the GAP kernel. You need this unless you get one of the executables below. This file is about 750 KBytes long. 'lib3r2.tar.Z': the *library of functions*. You need this. This file is about 1000 KBytes long. 'doc3r2.tar.Z': the *documentation*. Serves as LaTeX source for the printed manual and online documentation. Contains further installation information. This file is about 850 KBytes long. 'doc3r2.dvi.Z': the preformatted documentation. You need this if you do not have a *big* TeX. This file is about 1100 KByte long. 'grp3r2.tar.Z': various *group libraries*. Contains for example all primitive permutation groups of degree at most 50. This file is about 50 KByte long. 'two3r2.tar.Z': the library of *2-group* of size at most 256. This file is about 650 KByte long. 'thr3r2.tar.Z': the library of *3-groups* of size at most 729. This file is about 20 KByte long. 'tbl3r2.tar.Z': a library of *character tables* including all of the ATLAS. This file is about 2050 KByte long. 'tom3r2.tar.Z': a library of *table of marks* of various groups. This file is about 450 KByte long. 'anupq.tar.Z': the *ANU PQ* share library package. This file is about 350 KByte long. 'nq.tar.Z': the *NQ* share library package. This file is about 100 KByte long. 'weyl.tar.Z': the *Weyl* share library package. This file is about 50 KByte long. 'src3r2.zoo', 'lib3r2.zoo', 'doc3r2.zoo', 'grp3r2.zoo' 'tbl3r2.zoo', 'two3r2.zoo', 'thr3r2.zoo', 'tom3r2.zoo', 'anupq.zoo', 'nq.zoo', 'weyl.zoo': 'zoo' archives containing *exactly* the same files as the 'compress'-ed 'tar' archives above. The advantage of 'compress'-ed 'tar' archives is that 'uncompress' and 'tar' are widely available on UNIX systems. The advantage of 'zoo' archives is that they are smaller (about 30 percent) and that 'zoo' is more common on PC-s and Atari ST-s. (These files may not be available on all servers) We supply executables for machines that don't usually come with a C compiler or machines where the standard C compiler does not produce optimal results. If you have one of those machines it will be easier for you to get this executable instead of compiling GAP yourself. The following executables are available (again these files may not be available on all servers) 'gapexe.386': executable for IBM PC compatibles with an Intel 80386 or 80486 running MS-DOS 5.0 compiled with the GNU C 2.2.2 compiler. See below for the copyright. This file is about 500 KByte long. 'gapexe.next': executable for the NeXT (680?0) running NeXTstep 3.0 compiled with GNU C 2.3.3 compiler. This file is about 400 KByte long. 'gapexe.st': executable for Atari ST (680?0) running TOS compiled with the GNU C compiler. This file is about 450 KByte long. 'gapexe.su3': executable for SUN 3 (680?0) running SunOS 4.0 or higher compiled with the GNU C compiler. This file is about 500 KByte long. 'gapexe.su4': executable for SUN 4 (Sparc) running SunOS 4.1 or higher compiled with the GNU C 2.3.2 compiler. This file is about 600 KByte long. The following support files are also available (and again these files may not be available on all servers) 'compress.tar': 'compress' version 4.1. You need this program to uncompress the compressed tar files. Note however, that almost all UNIX systems these days already come with an executable 'compress'. This file is about 90 KByte long. 'patch.tar.Z': Larry Wall's 'patch' program version 2.0.2.0 (patchlevel 12u4). This program can be used to automatically apply upgrades. Note that older versions of 'patch' are *not* able to understand the unified 'diff' format used in the upgrade files. This file is about 70 KByte long. 'uud.c': 'uud' version 3.4. 'uud' is much better than the 'uudecode' that comes with most UNIX systems. This file is about 12 KByte long. 'zoo21.tar.Z': Rahul Dhesi's 'zoo' archiver version 2.1. You need this to unpack the *zoo-archives*. Note that the widespread version 2.01 will *not* work. This file is about 250 KByte long. 'zooexe.386': Executable of 'zoo' for IBM PC compatibles. This file is about 55 KByte long. 'zooexe.st': Executable of 'zoo' for the Atari ST. This file is about 80 KByte long. How to install GAP ================== The file 'install.tex' in 'doc3r2.tar.Z' contains extensive installation instructions. If however, you are one of those who never read manuals, here is a quick installation guide. First for UNIX. Make a directory for GAP, e.g., '~/gap/' or '/usr/local/lib/gap/'. Unpack the source archive 'src3r2.tar.Z' into the subdirectory 'src/'; unpack the library archive 'lib3r2.tar.Z' into the subdirectory 'lib/'; unpack the documentation 'doc3r2.tar.Z' into the subdirectory 'doc/'. If you have obtained the optional groups and character tables libraries 'grp3r2.tar.Z', 'tbl3r2.tar.Z', 'two3r2.tar.Z', 'thr3r2.tar.Z', and 'tom3r2.tar.Z', unpack them into the subdirectories 'grp/', 'tbl/', 'two/', 'thr/', or 'tom/'. Change into 'src/' and execute 'make' to see a list of possible targets; select a target, if in doubt use 'bsd' or 'usg', and make the kernel. In an appropriate directory, e.g., '~/bin/' or '/usr/local/bin/', create a shell script that executes the GAP kernel. This should look like exec /src/gap -m 4m -l /lib/ $* The option '-m' specifies the amount of initial memory; the option '-l' specifies where to find the library, if you get it wrong GAP complains gap: hmm, I cannot find 'lib/init.g', maybe use option '-l '? Change into 'doc/' and make the printed manual with the commands latex manual; latex manual; lp -dvi manual.dvi or something similar, according to your local custom for using LaTeX. Try something in GAP, e.g., the following exercises GAP quite a bit gap> m11 := Group( (1,2,3,4,5,6,7,8,9,10,11), (3,7,11,8)(4,10,5,6) );; gap> Number( ConjugacyClasses( m11 ) ); The result should be 10. Next for IBM PC compatibles with an Intel 80386 or 80486 running MS-DOS. Make a directory for GAP, e.g, 'c:\gap\'. Put the executable 'gapexe.386' into this directory calling it 'gap.exe'. Unpack the library archive 'lib3r2.zoo' into the subdirectory 'lib\'; unpack the documentation 'doc3r2.zoo' into the subdirectory 'doc\'. If you have obtained the optional groups and character table libraries 'grp3r2.zoo', 'tbl3r2.zoo', 'two3r2.zoo', 'thr3r2.zoo', and 'tom3r2.zoo', unpack them into the subdirectories 'grp\', 'tbl\', 'two\', 'thr\', and 'tom\'. In a directory in your path, e.g., 'c:\bin\', create a batch file 'gap.bat' that executes the GAP kernel. This should look like \gap -m 4m -l \lib\ %1 %2 %3 %4 The option '-m' specifies the amount of initial memory; the option '-l' specifies where to find the library, if you get it wrong GAP complains gap: hmm, I cannot find 'lib/init.g', maybe use option '-l '? Add the following line to your 'autoexec.bat' file SET GO32TMP= where should be the directory where you want GAP to put the swap file, e.g., 'c:\tmp'. The swap file will be called 'page????.386' and is normally removed when GAP exits. If 'GO32TMP' is not set, 'GCCTMP', 'TMP', 'TEMP' are checked (in this order). If neither is set, GAP will not swap to disk. *Note that you must reboot before this change in 'autoexec.bat' takes effect*. Change into 'doc\' and make the printed manual with the commands latex manual; latex manual; print manual.dvi or something similar, according to your local custom for using LaTeX. Try something in GAP, e.g., the following exercises GAP quite a bit gap> m11 := Group( (1,2,3,4,5,6,7,8,9,10,11), (3,7,11,8)(4,10,5,6) );; gap> Number( ConjugacyClasses( m11 ) ); The result should be 10. Note that GAP for the 386 will use up to 128 MByte of extended memory (using XMS, VDISK memory allocation strategies) or up to 128 MByte of expanded memory (using VCPI programs, such as QEMM and 386MAX) and up to 128 MByte of disk space for swapping. Further note that GAP for the 386 will *not* run under Windows (because it does not support DPMI). If you hit -'C' the DOS extender ('go32') catches it and aborts GAP immediately. The keys -'Z' and -'C' can be used instead to interupt GAP. The arrow keys , , , , , , and can be used for command line editing with their intuitive meaning. Pathnames may be given inside GAP using either shlash ('/') or backslash ('\') as a separator (though '\' must be escaped in strings of course). The system dependent part of GAP for the 386 ('sysdos.c') was written by Steve Linton (111 Ross St., Cambridge, CB1 3BS, UK, +44 223 411661, 'sl25@cus.cam.ac.uk'). He assignes the copyright to the Lehrstuhl D fuer Mathematik. Many thanks to Steve Linton for his work. GAP for the 386 was compiled with DJ Delorie's port of the Free Software Foundation's GNU C compiler version 2.1. The compiler can be obtained by anonymous 'ftp' from 'grape.ecs.clarkson.edu' where it is in the directory 'pub/msdos/djgpp'. Many thanks to the Free Software Foundation and DJ Delorie for this amazing piece of work. The GNU C compiler is Copyright (C) 1989 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA under the terms of the GNU General Public License (GPL). Note that the GNU GPL states that the mere act of compiling does not affect the copyright status of GAP. The modifications to the compiler to make it operating under MS-DOS, the functions from the standard library 'libpc.a', the modifications of the functions from the standard library 'libc.a' to make them operate under MS-DOS, and the DOS extender 'go32' (which is prepended to 'gapexe.386') are Copyright (C) 1991 DJ Delorie, 24 Kirsten Ave, Rochester NH 03867-2954, USA also under the terms of the GNU GPL. The terms of the GPL require that we make the source code for 'libpc.a' available. They can be obtained by writing to Steve Linton (however, it may be easier for you to 'ftp' them from 'grape.ecs.clarkson.edu' yourself). They also require that GAP falls under the GPL too, i.e., is distributed freely, which it basically does anyhow. The functions in 'libc.a' that GAP for the 386 uses are Copyright (c) 1988 Regents of the University of California. under the following terms All rights reserved. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. The Future of GAP ================= See ye not all these things? Verily I say unto you, there shall not be left here one stone upon another, that shall not be thrown down. (Matthew 24:2) Clearly GAP will contain bugs, as any system of this size, though currently we know none. Also there are things that we feel are still missing, and that we would like to include into GAP. We will continue to improve and extend GAP. We will release new versions quite regulary now, and about three or four upgrades a year are planned. Make sure to get these, since they will in particular contain bug-fixes. We are committed however, to staying upward compatible from now on in future releases. That means that everything that works now will also work in those future releases. This is different from the quite radical step from GAP 2.4 to GAP 3.1, in which almost everything was changed. Of course, we have ideas about what we want to have in future versions of GAP. However we are also looking forward to your comments or suggestions. The GAP Forum ============= We have also established a GAP forum, where interested users can discuss GAP related topics by e-mail. In particular this forum is for questions about GAP, general comments, bug reports, and maybe bug fixes. We, the developers of GAP, will read this forum and answer questions and comments, and distribute bug fixes. Of course others are also invited to answer questions, etc. We will also announce future releases of GAP on this forum. So in order to be informed about bugs and their fixes as well as about additions to GAP we recommend that you subscribe to the GAP forum. To subscribe send a message to 'listserv@samson.math.rwth-aachen.de' containing the line 'subscribe gap-forum ', where should be your full name, not your e-mail address. You will receive an acknowledgement, and from then on all e-mail messages sent to 'gap-forum@samson.math.rwth-aachen.de'. 'listserv@samson.math.rwth-aachen.de' also accepts the following requests: 'help' for a short help on how to use 'listserv', 'unsubscribe gap-forum' to unsubscribe again, 'recipients gap-forum' to get a list of subscribers, and 'statistics gap-forum' to see how many e-mail messages each subscriber has sent so far. If you have further questions or comments do not hesitate to write to me 'Martin.Schoenert@Math.RWTH-Aachen.DE'. Thank you for your attention, Martin. -- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From sam@ernie.math.rwth-aachen.de Fri Feb 19 20:24:10 1993 From: sam@ernie.math.rwth-aachen.de "Thomas Breuer" Date: Fri, 19 Feb 93 20:24:10 +0100 Subject: Dear Mrs. and Mr. Forum, many things have changed from GAP-3.1 to GAP-3.2, and there are a few cases where this means not only extensions but the possibility that a function will cause strange results in GAP-3.2 although it worked well in GAP-3.1. Maybe the most nasty case is the behaviour of strings. As said in the announcement of GAP-3.2, now strings are also lists, thus 'IsList( )' yields 'true' for a string . Suppose you have a function that shall append a suffix to strings, and whose argument can be either a string or a list of strings, then in GAP-3.1 it may look like this. gap> test := function( obj ) > if IsList( obj ) then > return List( obj, y -> ConcatenationString( y, ".suffix" ) ); > else > return ConcatenationString( obj, ".suffix" ); > fi; > end;; gap> test( "nolist" ); "nolist.suffix" gap> test( [ "l", "i", "s", "t" ] ); [ "l.suffix", "i.suffix", "s.suffix", "t.suffix" ] In GAP-3.2 this function does not work. gap> test( "nolist" ); Error, Append: must be a list at Append( res, str ) ... in ConcatenationString( y, ".suffix" ) called from fun( i ) called from List( obj, function ( y ) ... end ) called from test( "nolist" ) called from main loop brk> y; 'n' brk> quit; gap> test( [ "l", "i", "s", "t" ] ); [ "l.suffix", "i.suffix", "s.suffix", "t.suffix" ] gap> [ 'l', 'i', 's', 't' ]; "list" gap> List( last ); [ "l", "i", "s", "t" ] This is because the string '"nolist"' now is a list, and 'test' tries to concatenate its entries with the suffix; but the entries of '"nolist"' aren't strings but characters (which are printed in single quotes). So a string is equivalent to the list of its characters. On the other hand, a list of strings is not itself a string; as in GAP-3.1, the function 'List' returns for a string the list of strings containing single letters. Of course this is not the real problem, the solution is simply to ask for the more special case of being a string first. But there is a problem, and as everybody will suspect who read the messages to the GAP forum last week, it is a problem with empties. gap> IsList( "" ); IsString( "" ); true true gap> IsList( [] ); IsString( [] ); true true gap> [] = ""; true (By the way, what should the function 'test' defined above return in case of input '""' or '[]'? In GAP-3.1 there was a well-defined difference.) Empty string '""' and empty list '[]' are the same now, with one exception: In contrary to nonempty lists of characters, the empty list is not converted into a string, it is printed as '[ ]'. And printing one of these objects is the problem. Suppose you want to write a program that prints strings enclosed in '"', and prints other objects as they are printed by 'Print', in GAP-3.1 this function worked. gap> MyPrint := function( obj ) > if IsString( obj ) then > Print( "\"", obj, "\"\n" ); > else > Print( obj, "\n" ); > fi; > end;; gap> MyPrint( [] ); "[ ]" gap> MyPrint( "" ); "" We want the empty list to be printed as '[ ]', and the empty string as '""', so we must be able to distinguish the two objects. The only solution is to ask for the information that also GAP-3.2 uses to distinguish them. This can be done using the function 'TYPE' that returns '"string"' for '""', and '"list"' for '[]'. Note that this is one of the VERY FEW situations where an undocumented function like 'TYPE' is of interest for the user, normally one should avoid using such functions. gap> MyPrint := function( obj ) > if IsString( obj ) and TYPE( obj ) = "string" then > Print( "\"", obj, "\"\n" ); > else > Print( obj, "\n" ); > fi; > end;; gap> MyPrint( [] ); [ ] gap> MyPrint( "" ); "" Thomas Breuer (sam@ernie.math.rwth-aachen.de) From jcbhrb@cerf.net Mon Feb 22 07:28:27 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Mon, 22 Feb 93 07:28:27 +0100 Subject: Direct character calculation gap-forum@samson.math.rwth-aachen.de Just a couple of comments in regards to my question last week about the direct calculation of characters. First: many thanks to Thomas Breuer for a great answer; now I am tempted to bother the forum with more questions :-) . Second I have just finished installing gap3.2 on a DEC Ultrix workstation and on a PC. It looks fantastic! it took just a few minutes on the PC to do the calculations below for the characters of <2,3,4> and <2,3,5> -- it took the DEC 3100 a bit longer to do the same. a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); g4 := Group(a,b,c,z); g5 := Group(a,b,c,z); g4.relators := [a^2*z^-1,b^3*z^-1,c^4*z^-1,a*b*c*z^-1,z^2]; g5.relators := [a^2*z^-1,b^3*z^-1,c^5*z^-1,a*b*c*z^-1,z^2]; group4:=OperationCosetsFpGroup(g4,Subgroup(g4,[IdWord])); group5:=OperationCosetsFpGroup(g5,Subgroup(g5,[IdWord])); chr4 := CharTable(group4); chr5 := CharTable(group5); DisplayCharTable(chr4); 2 4 2 1 3 4 3 1 3 3 1 . 1 . 1 . 1 . 1a 4a 6a 8a 2a 8b 3a 4b 2P 1a 2a 3a 4b 1a 4b 3a 2a 3P 1a 4a 2a 8b 2a 8a 1a 4b 5P 1a 4a 6a 8b 2a 8a 3a 4b 7P 1a 4a 6a 8a 2a 8b 3a 4b X.1 1 1 1 1 1 1 1 1 X.2 1 -1 1 -1 1 -1 1 1 X.3 2 . -1 . 2 . -1 2 X.4 2 . 1 A -2 -A -1 . X.5 2 . 1 -A -2 A -1 . X.6 3 -1 . 1 3 1 . -1 X.7 3 1 . -1 3 -1 . -1 X.8 4 . -1 . -4 . 1 . A = -E(8)+E(8)^3 = -ER(2) = -r2 DisplayCharTable(chr5); 2 3 2 1 1 3 1 1 1 1 3 1 . 1 . 1 . 1 . . 5 1 . . 1 1 1 . 1 1 1a 4a 6a 10a 2a 5a 3a 5b 10b 2P 1a 2a 3a 5b 1a 5b 3a 5a 5a 3P 1a 4a 2a 10b 2a 5b 1a 5a 10a 5P 1a 4a 6a 2a 2a 1a 3a 1a 2a 7P 1a 4a 6a 10b 2a 5b 3a 5a 10a X.1 1 1 1 1 1 1 1 1 1 X.2 2 . 1 A -2 -A -1 -*A *A X.3 2 . 1 *A -2 -*A -1 -A A X.4 3 -1 . A 3 A . *A *A X.5 3 -1 . *A 3 *A . A A X.6 4 . 1 -1 4 -1 1 -1 -1 X.7 4 . -1 1 -4 -1 1 -1 1 X.8 5 1 -1 . 5 . -1 . . X.9 6 . . -1 -6 1 . 1 -1 A = -E(5)^2-E(5)^3 = (1+ER(5))/2 = 1+b5 Thanks to all the developers for a great tool. Jacob Hirbawi JcbHrb@CERF.net From sl25@cus.cam.ac.uk Tue Feb 23 09:17:50 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Tue, 23 Feb 93 09:17:50 +0100 Subject: Change List Is there a comprehensive list of changes from 3.1 to 3.2? I've seen the "what's new" list in the announcement, but I'd be interested in a more detailed list. Steve From schumach@math.wisc.edu Tue Feb 23 09:21:36 1993 From: schumach@math.wisc.edu "Lee Schumacher" Date: Tue, 23 Feb 93 09:21:36 +0100 Subject: garbage collection I've been using gap with the -g option, so I have some idea what's going on during long computations. Does anyone know what the performance penalty is ? thanks, Lee Schumacher From mendel@ccu.umanitoba.ca Tue Feb 23 09:25:40 1993 From: mendel@ccu.umanitoba.ca "N. S. Mendelsohn" Date: Tue, 23 Feb 93 09:25:40 +0100 Subject: GAP on Mac The new Mac version is essentially completed. I will send you the date at which it can be ftp'd. Harry Lakser has done a fantastic job on the new interface. The read me letter will contain all details. N. S. Mendelsohn From michel@dmi.ens.fr Tue Feb 23 11:06:00 1993 From: michel@dmi.ens.fr "Jean Michel" Date: Tue, 23 Feb 93 11:06:00 +0100 Subject: First impressions of 3.2 I have just installed 3.2 on my PC (a 66Mhz 486). The number of gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude that much of the improvement on the PC must be due to a better C compiler. Impressive! (and congratulations!) Also I like very much the facility offered by {} indexing, which I timed as being 5 times faster than Sublist. However, I find myself writing all the times things like: l{[4..7]} or l{[3,5,9]} could not a syntax like l{4..7} or l{3,5,9} be accepted to mean the same? Also, polynomials are great, but I have trouble using them. Maybe it is just me or the documentation: I have a polynomial over the integers which I know is a product of cyclotomic polynomials plus a constant. I want to find out exactly what product and what constant. As it is I cannot do that, because I did not find the routine to do the Euclidean division of two polynomials. I found a routine for the Gcd, but not for the division. Did I miss something? One last thing: I notices that 3+[] and []+3 are now both accepted and return []. I hastily changed my function plus:=function(a,b) if Length(a)=0 then return a; elif Length(b)=0 then return b; else return a+b; fi; end; to calls of '+' again. I say hastily because []+[] still does not work! I had to go back to the old version for the case of equal-length vectors. What's funny is that the error message has changed for that case: it used to be 'Vectors: '+' incompatible types' it is now: '+ not defined for Lists' Jean MICHEL, DMI, ENS From borbor@divsun.unige.ch Tue Feb 23 11:38:39 1993 From: borbor@divsun.unige.ch "Borcic Boris" Date: Tue, 23 Feb 93 11:38:39 +0100 Subject: GAP for MAC, new version ? I think I recall a new version of GAP for the Macintosh was promised maybe mid-december for maybe mid-january by the authors of the original port. Is it still in the works ? Regards, Boris Borcic --- (12^2-55)^2-12^2*55-1=0 From fceller@bert.math.rwth-aachen.de Tue Feb 23 13:32:47 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 23 Feb 93 13:32:47 +0100 Subject: Re: Re: GAP on super/parallel computers Dawn Endico writes: >Archives?!? That reminds me that I've been meaning to ask whether >anyone has gap-forum archives available on a gohper server. FTP? we do not provide a gopher service, but the old mails to gap-forum can be found on "samson.math.rwth-aachen.de" in "tmp": -r--r--r-- 1 ftp system 96688 Sep 21 17:39 forum92b.txt -r--r--r-- 1 ftp system 112618 Oct 8 09:42 forum92c.txt -r--r--r-- 1 ftp system 129896 Jan 26 17:27 forum92d.txt best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Tue Feb 23 13:55:41 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 23 Feb 93 13:55:41 +0100 Subject: Re: garbage collection >I've been using gap with the -g option, so I have some idea >what's going on during long computations. Does anyone know >what the performance penalty is ? there is no performance penalty, except for the time used to actually print the message on the screen. best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:04:06 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 23 Feb 93 14:04:06 +0100 Subject: Re: First impressions of 3.2 >I have just installed 3.2 on my PC (a 66Mhz 486). The number of >gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the >improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude >that much of the improvement on the PC must be due to a better >C compiler. Impressive! (and congratulations!) It is more or less the same compiler, the performance loss in GAP 3.1 is due to the *very* costly routine that checks for and , because the program has to switch from 32bit-mode to msdos-mode. You can now set the interrupt check frequency using the "-z" flag. The default value is 20. best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:32:26 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 23 Feb 93 14:32:26 +0100 Subject: Re: First impressions of 3.2 >I found a routine for the Gcd, but not for >the division. Did I miss something? no, you are not missing anything, the routine 'EuclideanQuotient' was not ready before the final deadline. The following routine should work for polynomials over fields: ----------------------------------------------------------------------------- EuclideanQuotient := function ( f, g ) local m, n, i, k, c, q, R, val; # and must have the same field if f.baseRing <> g.baseRing then Error( " and must have the same base ring" ); fi; # and they must be ordinary polynomials if f.valuation < 0 then Error( " must not be a laurent polynomial" ); fi; if g.valuation < 0 then Error( " must not be a laurent polynomial" ); fi; R := f.baseRing; # if is zero signal an error if 0 = Length(g.coefficients) then Error( " must not be zero" ); fi; # if is zero return it if 0 = Length(f.coefficients) then return f; fi; # remove the valuation of and f := ShiftedCoeffs( f.coefficients, f.valuation ); g := ShiftedCoeffs( g.coefficients, g.valuation ); # Try to divide by q := []; n := Length(g); m := Length(f) - n; for i in [ 0 .. m ] do c := f[m-i+n] / g[n]; for k in [ 1 .. n ] do f[m-i+k] := f[m-i+k] - c * g[k]; od; q[m-i+1] := c; od; # return the polynomial return Polynomial( R, q, 0 ); end; ----------------------------------------------------------------------------- best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Tue Feb 23 14:39:28 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 23 Feb 93 14:39:28 +0100 Subject: Re: First impressions of 3.2 >What's funny is that the error message has changed for that case: >it used to be 'Vectors: '+' incompatible types' >it is now: '+ not defined for Lists' This is because the internal mechanisms for accessing lists, plain list, vectors, sets and strings have changed (in order to unify them). best wishes Frank Celler From sam@ernie.math.rwth-aachen.de Tue Feb 23 19:07:27 1993 From: sam@ernie.math.rwth-aachen.de "Thomas Breuer" Date: Tue, 23 Feb 93 19:07:27 +0100 Subject: Dear Mrs. and Mr. Forum, in his latest message Steve Linton writes > Is there a comprehensive list of changes from 3.1 to 3.2? Unfortunately such a list does not exist. But I try to give an overview (without guarantee of completeness). There are five different kinds of changes. 1) New features in the GAP language. 2) New files in the GAP library, a result of new structures in GAP. 3) New functions for structures that already existed in GAP-3.1. 4) New data. 5) New behaviour of objects that already existed in GAP-3.1. ad 1): These are the five extensions pointed out in the announcement, namely the access to sublists via curly brackets '{' and '}', the existence of permutations acting on points larger than 65535, the generalization of ranges, the generalization of matrices, and the representation of strings equal to lists. Additionally, GAP-3.2 is a little bit more exact in detecting global variables in user-defined functions. ad 2): The following files are new in GAP-3.2. agctbl.g: AgGroup specific parts of the Dixon-Schneider algorithm cdaggrp.g: functions for calculating the degrees of the irreducible characters of a solvable group chevgrp.g: information about Chevalley-groups (used in "recsl.g") ctgapmoc.g: functions used for conversion of GAP tables to MOC format ctlattic.g: functions mainly dealing with lattices in the context of character tables fpsgpres.g: functions that compute presentations of subgroups of finitely presented groups fptietze.g: functions that compute presentations of subgroups of finitely presented groups grpctbl.g: the Dixon-Schneider Algorithm for computing character tables of groups permag.g: functions that calculate composition series for solvable permutation groups and convert such groups into ag groups permcose.g: functions to work with cosets of subgroups in permutation groups permcser.g: functions to compute composition series for permutation groups and related stuff permctbl.g: permutation group specific parts of the Dixon-Schneider algorithm permprod.g: functions for group products and group constructions polyfin.g: functions for polynomials over finite fields polyfld.g: functions for polynomials over fields polynom.g: functions that are dispatchers for polynomial functions, and the polynomial arithmetic polyrat.g: functions for polynomials over finite fields recsl.g: function which help to recognize SL(q,n) tom.g: functions dealing with Tables Of Marks Also new are the share library packages in directories 'anupq', 'nq', and 'weyl', as described in the announcement. ad 3): The following functions are new (Note that additionally some NAMES of functions meanwhile have changed, e.g., all functions defined in file 'pq.g'.). AGDoubleCosets, AddDecMats, AscendingChain, BasicSetBrauerTree, BetaSet, BrauerTree, CalcDoubleCosets, CanonicalCosetElement, CanonicalRightTransversal, CharacteristicPolynomial, CycleStructurePerm, DifferenceBlist, ElementVector, Exponent, Extension, FactorAgSubgroup, FieldMatrices, FieldMatricesOps, FiniteFieldMatrices, FiniteFieldMatricesOps, GenRelOrdersAgGroup, IntegralizedMat, IntersectionBlist, IsIdentical, LeftCosetAgGroupOps, LinearIndependentColumns, MainEntryCCEAgGroup, MakeStabChainRandom, MaximalBlocks, MinMaxLatticeRelation, MinimalPolynomial, OnCanonicalCosetElements, PCore, PadicCoefficients, PermCharInfo, PermutationCharacter, PrintClassSubgroupLattice, PrintGroupSubgroupLattice, PrintMaxSubgroupLattice, PrintMinSubgroupLattice, Radical, RefinedChain, RelatorRepresentatives, RelsSortedByStartGen, RequirePackage, RightCosetMatGroupOps, Save, SetPrintLevel, SortCharTable, UnionBlist, (Some of them are self-explanatory, all can be looked up in the manual resp. online-help.) ad 4): There is a library of 3-groups, as said in the announcement. Additionally there are functions computing classical (matrix) groups, namely 'GeneralLinearGroup', 'SpecialLinearGroup', 'SymplecticGroup', 'GeneralUnitaryGroup', and 'SpecialUnitaryGroup'. The about 60 new tables in the character table library are mainly those of maximal subgroups of sporadic simple groups. Also new is a component 'maxes' in the table record of tables of sporadic simple groups, a list containing the names of the tables their maximal subgroups; note that not yet all these tables are available in GAP. ad 5): This is of course the most interesting kind of changes, since everything listed up here will probably cause trouble for someone who has written programs for GAP-3.1. First, some functions that were written in the GAP language in 3.1 have been put into the kernel, like 'OnPoints'. The different behaviour is mainly that such functions work much faster now, and in some cases errors are detected at an earlier stage. Next, some function names have changed, that is, the manual knows them under a new name; but we hope that GAP-3.2 allows you to access them also under the old name. The extensions of the language cause different behaviour of some functions; 'IsList' will return 'true' also for lists in GAP-3.2 (which makes it difficult to distinguish empty list and empty string), and 'IsRange' returns 'true' for the more general type of ranges in GAP-3.2, which also may cause some strange results when using code written for GAP-3.1. The format of character tables in the library has changed. This should not be of any interest for the user, except that some redundant data (like 'indicator' components ) is simply omitted in the GAP-3.2 library. I hope this list is a little bit useful. Sorry again that we have no complete and official list of changes. For the next release we should provide this. Thomas Breuer (sam@ernie.math.rwth-aachen.de) From felsch@samson.math.rwth-aachen.de Wed Feb 24 12:26:10 1993 From: felsch@samson.math.rwth-aachen.de "Volkmar Felsch" Date: Wed, 24 Feb 93 12:26:10 +0100 Subject: Re: Change List Yesterday, Thomas Breuer has already given a first answer to Steve Linton's question > Is there a comprehensive list of changes from 3.1 to 3.2? I would like to add to his list a few more remarks concerning changes and extensions of functions described in the manual chapters "Groups", "Table of Marks", "Finite Polycyclic Groups", and "Finitely Presented Groups". Chapter "Groups" ---------------- Facilities for computing and printing the subgroup lattice of a given group have been added, and an explicit description of the respective new functions Lattice PrintClassSubgroupLattice SetPrintLevel has been added to the manual setcion. The description of the TableOfMarks function has been removed from the setcion and moved to an own chapter. Chapter "Table of Marks" ------------------------ The function TableOfMarks to compute Burnside's table of marks of a finite group has been changed and extended by several new functions for handling such tables. The new chapter "Table of Marks" describes all these functions: TableOfMarks Marks NrSubs WeightsTom MatTom TomMat DecomposedFixedPointVector TestTom DisplayTom NormalizerTom IntersectionsTom IsCyclicTom FusionCharTableTom PermCharsTom MoebiusTom CyclicExtensionsTom IdempotentsTom ClassTypesTom ClassNamesTom TomCyclic TomDihedral TomFrobenius Chapter "Finite Polycyclic Groups" ---------------------------------- Since the release of version 3.1 some functions have been renamed or replaced by global functions: pQuotient -> PQuotient, PrimeQuotient pQpresentationSave -> Save pQpresentationRestore -> PQp pQpresentationPrint -> Print pQInit -> InitPQp pQWeight -> Weight NextClass -> NextClassPQp pAbelianQuotient -> FirstClassPQp DefiningGenerators -> Factorization They are now properly described in the GAP 3.2 manual release. Chapter "Finitely presented group" ---------------------------------- This chapter has been extended by six sections which describe new functions for handling group presentations. As GAP does never allow to alter any presentation which is part of a group record, we have introduced so called "presentation records" as a new type of GAP objects which are permitted to be changed. The functions PresentationFpGroup FpGroupPresentation TzPrintStatus TzPrintGenerators TzPrintRelators TzPrintPresentation TzPrint TzPrintLengths TzPrintPairs TzPrintOptions Save AddGenerator AddRelator RemoveRelator allow to create, administrate, print, or alter such pressentation records. In particular, Tietze transformations can be applied to them via the functions SimplifiedFpGroup SimplifyPresentation TzGo TzGoGo TzEliminate TzSearch TzSearchEqual TzFindCyclicJoins TzSubstitute TzSubstituteCyclicJoins Moreover, we offer new functions PresentationSubgroup PresentationSubgroupMtc PresentationSubgroupRrs PresentationNormalClosure PresentationNormalClosureRrs DecodeTree for computing a presentation of a subgroup of a finitely presented group using the so called Modified Todd-Coxeter method or the Reduced Reidemeister-Schreier algorithm. I hope these remarks will be another help in figuring out at least some features which are new in GAP 3.2 . Volkmar Felsch From michel@dmi.ens.fr Wed Feb 24 18:31:11 1993 From: michel@dmi.ens.fr "Jean Michel" Date: Wed, 24 Feb 93 18:31:11 +0100 Subject: ranges The new ranges are an improvement, but... I find the fact that - must be divisible (the error message says divisable which is a misspelling) by to be slightly annoying. I had in my code thinks like: [1..QuoInt(n+1,2)]*2-1 to specify the odd integers smaller than n, and [1..QuoInt(n,2)]*2 to specify the even integers less than n. I hoped to be able to rewrite these as [1,3..n] and [2,4..n] but the first one works only for n odd and the second for n even! One has to use [1,3..n-1+(n mod 2)] and [2,4..n-(n mod 2)] which is less pleasant and efficient. What is the rationale for the restriction? From kaskel@math.berkeley.edu Fri Feb 26 17:42:28 1993 From: kaskel@math.berkeley.edu "Bruce Kaskel" Date: Fri, 26 Feb 93 17:42:28 +0100 Subject: Could someone possibly tell me what I am doing wrong here? This is my first time using GAP and I can't see why this doesn't work. Why does it hit this error? Thank you in advance for any help given. You can e-mail to me at kaskel@math.berkeley.edu --------------------------------------------------------------------------- gap> s4:=SymmetricGroup4 (4); Group( (1,4), (2,4), (3,4) ) gap> cc:=ConjugacyClassesSubgroups(s4); [ ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (2,3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (1,2)(3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4), (1,2) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (2,3,4), (3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3)(2,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3,2,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4), (1,2)(3,4), (1,3)(2,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (1,2)(3,4), (1,3)(2,4), (2,3,4) ] ) ), ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Group( (1,4), (2,4), (3,4) ) ) ] gap> cc2:=cc[2]; ConjugacyClassSubgroups( Group( (1,4), (2,4), (3,4) ), Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4) ] ) ) gap> r:=Representative(cc2); Subgroup( Group( (1,4), (2,4), (3,4) ), [ (3,4) ] ) gap> g:=Group(r); Group( (3,4) ) gap> 2syl:=SylowSubgroup(g,2); Error, Record: element 'orbit' must have an assigned value at while Length( G.orbit ) mod p <> 0 ... in G.operations.SylowSubgroup( G, p ) called from SylowSubgroup( g, 2 ) called from main loop brk> --------------------------------------------------------------------------- From hwb@machnix.mathematik.uni-stuttgart.de Fri Feb 26 20:53:03 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Fri, 26 Feb 93 20:53:03 +0100 Subject: porting GAP to OS/2 2.0 with emx Hello! I have just acquired GAP and have no experience with it. Even before trying it at all I thought it might be nice to have it working on my PC under OS/2 2.0. Has anybody ported GAP to OS/2 2.0? Let me tell you what I did so far: I compiled GAP 3.2 using the emx0.8f port of gcc. Since emx provides a very unix-like environment, I used sysunix.c and SYS_IS_USG. After changing only about 4 lines, GAP compiled without problems and is now working under OS/2 2.0, including the command line editor. Since emx produces bound executables for DOS and OS/2 2.0, I am wondering why the DOS port of GAP was done using DJ Delorie's gcc / DOS extender and not emx. Some work remains to be done, I admit. At least the command line editing should be changed so that the cursor keys can be used. Before spending any time on this I'd like some feedback: Has anybody already done this? To the GAP developers: Wouldn't it be much nicer to have a single executable of GAP for DOS and OS/2? Regards, Harald P.S.: private Mail an mich kann man natuerlich auch auf Deutsch schreiben. -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From martin@bert.math.rwth-aachen.de Mon Mar 1 11:30:30 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 11:30:30 +0100 Subject: Re: GAP on super/parallel computers In his e-mail message of 1993/02/17, Frederick Ford wrote I have an opportunity to get some "free" time on either a super computer or a parallel computer. The super computer options are: OS C compiler IBM ES-9000 AIX/370 AIX/370 C compiler IBM RS-6000 AIX AIX XL C compiler/6000 Cray-YMP UNICOS Cray standard C compiler The easiest option is the RS/6000 (usually those machines are considered workstations or servers, not super computers). Porting GAP to the ES-9000 (under AIX) should also be reasonably simple. I would expect a ES-9000 to run GAP about a factor of two faster than a large RS/6000. Which machine is better depends on the number of other users on each system, the amount of memory installed, etc. GAP does *not* run on Crays. The reason is that GAP makes certain assumptions about the format of pointers that aren't valid on Crays. It could probably be made to work, but (as far as I know) nobody is currently trying. It wouldn't make much sense because GAP could not make use of the special hardware (vector units, etc.) that make Crays so fast for numerical code. So GAP on a Cray probably wouldn't run significantly faster than on a fast UNIX workstation (maybe twice or three times as fast). He continues: The parallel computer is a Connection Machine (massively parallel I'm told). The OS is System V, BSD 4.3 compatible. I don't have any details on the C compiler version, but it's whatever Thinking Machines is distributing as their "standard" C compiler. GAP contains no explicit parallel constructs, and I doubt that there are many place where the compiler could automatically find parallelizable code. I don't think you should try. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Mon Mar 1 11:57:14 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 11:57:14 +0100 Subject: Re: In his e-mail message of 1993/02/26, Bruce Kaskel writes: Could someone possibly tell me what I am doing wrong here? gap> s4 := SymmmetricGroup( 4 );; gap> cc := ConjugacyClassesSubgroups( s4 );; gap> cc2 := cc[2];; gap> r := Representative( cc2 );; gap> g := Group( r ); Group( (3,4) ) gap> 2syl := SylowSubgroup( g, 2 ); Error, Record: element 'orbit' must have an assigned value at ... This is a bug in GAP 3.1 (patchlevel 0). It is fixed in the first upgrade to V3R1P1 and in GAP 3.2. The problem was that 'PermGroupOps.SylowSubgroup' assumed that once the size of a permutation group is known (and it is known for 'g', since it was known for 'r'), also a stabilizer chain is known (but 'g' has no stabilizer chain, because this is not copied by 'Group'). Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From sl25@cus.cam.ac.uk Mon Mar 1 13:39:49 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Mon, 1 Mar 93 13:39:49 +0100 Subject: Re: porting GAP to OS/2 2.0 with emx Harald Boegeholz writes: > > I have just acquired GAP and have no experience with it. Even before > trying it at all I thought it might be nice to have it working on my > PC under OS/2 2.0. > > Has anybody ported GAP to OS/2 2.0? Not as far as I know. > > Let me tell you what I did so far: > > I compiled GAP 3.2 using the emx0.8f port of gcc. Since emx provides a > very unix-like environment, I used sysunix.c and SYS_IS_USG. After > changing only about 4 lines, GAP compiled without problems and is now > working under OS/2 2.0, including the command line editor. Since emx > produces bound executables for DOS and OS/2 2.0, I am wondering why > the DOS port of GAP was done using DJ Delorie's gcc / DOS extender and > not emx. Basically because I didn't have an OS/2 system. How do the emx produced DOS executables behave? What expanded memory/swapping protocols will they use? How fast are they? Apart from the kbhit() problem identified a few weeks ago, the DJGPP executables seem to work pretty well in a variety of environments. > > Some work remains to be done, I admit. At least the command line > editing should be changed so that the cursor keys can be used. Before > spending any time on this I'd like some feedback: Has anybody already > done this? Again, not as far as I know. The DJGPP port (sysdos.c or whatever it`s called now) uses various arrow keys and so on, but I doubnt that you could use the same code. > > To the GAP developers: Wouldn't it be much nicer to have a single > executable of GAP for DOS and OS/2? > I would certainly think so, but there seem to be far more DOS than OS/2 users, so DOS performance is an important consideration. Steve Linton From hwb@machnix.mathematik.uni-stuttgart.de Mon Mar 1 15:33:49 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Mon, 1 Mar 93 15:33:49 +0100 Subject: porting GAP to OS/2 2.0 with emx Date: Mon, 1 Mar 93 13:42:12 +0100 From: Steve Linton To: Multiple recipients of list Subject: Re: porting GAP to OS/2 2.0 with emx Harald Boegeholz writes: > > I have just acquired GAP and have no experience with it. Even before > trying it at all I thought it might be nice to have it working on my > PC under OS/2 2.0. > > Has anybody ported GAP to OS/2 2.0? Not as far as I know. > > Let me tell you what I did so far: [...] How do the emx produced DOS executables behave? What expanded memory/swapping protocols will they use? How fast are they? Apart from the kbhit() problem identified a few weeks ago, the DJGPP executables seem to work pretty well in a variety of environments. Sinc I just joined the GAP-forum, I don't know about "the kbhit()-problem". Could you tell me what that was? As for the DOS performance of emx: I haven't made any speed measurements yet, but I can do that sometime. emx does not support DPMI, but does support VCPI or XMS. It can also coexist with VDISK.SYS 3.3 and later. emx uses all available memory, whether conventional, extended or expanded memory. But it does not use extended AND expanded memory at the same time. emx will swap to disk if there isn't enough real memory. On the whole I think that it is comparable to DJGPP/GO32, with the additional benefit that it produces executables that work under OS/2 2.0 as well. I cannot imagine why it should be slower, but I will try that soon. > > Some work remains to be done, I admit. At least the command line > editing should be changed so that the cursor keys can be used. Before > spending any time on this I'd like some feedback: Has anybody already > done this? Again, not as far as I know. The DJGPP port (sysdos.c or whatever it`s called now) uses various arrow keys and so on, but I doubnt that you could use the same code. If nobody else is doing it, I will look into that as my spare time allows. mfg hwb -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From sl25@cus.cam.ac.uk Mon Mar 1 17:23:22 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Mon, 1 Mar 93 17:23:22 +0100 Subject: Re: porting GAP to OS/2 2.0 with emx > Sinc I just joined the GAP-forum, I don't know about "the > kbhit()-problem". Could you tell me what that was? The DJGPP version was spending a rather large proportion of its time switching back into 8086 mode to check if a key had been pressed (in case it was an interrupt key). By reducing the frequency of such tests (see the GAP-3.2 sysdos.c) a substantial performance improvement was acheived. Steve From martin@bert.math.rwth-aachen.de Mon Mar 1 20:35:40 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 20:35:40 +0100 Subject: Re: First impressions of 3.2 In his e-mail message of 1993/02/23, Jean Michel writes I have just installed 3.2 on my PC (a 66Mhz 486). The number of gapstones has jumped from 16000 in 3.1 to 28000 in 3.2! Since the improvement seen on the Sun sparc SLC is just 13000 to 16000, I conclude that much of the improvement on the PC must be due to a better C compiler. Impressive! (and congratulations!) As Frank already noted, the main reason for the performance jump is that GAP now checks for user interrupt less frequently. He continues: Also I like very much the facility offered by {} indexing, which I timed as being 5 times faster than Sublist. However, I find myself writing all the times things like: l{[4..7]} or l{[3,5,9]} could not a syntax like l{4..7} or l{3,5,9} be accepted to mean the same? We are giving some thoughts to extend the concept of lists to the more general concept of a table. In a table the index could be any object, not just a positive integer. So you could, for example, index into a table with permutations, lists, etc. At one time the syntax I had in mind for sublist extraction made it neccessary to always have a list expression in the sublist construct '{}', so that GAP could distinguish between extracting a single element at an index given by a list and extracting a whole sublist at indices given by a list. The current syntax cannot lead to such a confusion, so 'l{4..7}' or 'l{3,5,9}' could -- and probably will -- be accepted in a future version. He continues: One last thing: I notices that 3+[] and []+3 are now both accepted and return []. Yes. But you probably should not use this. Or at least if you use this be aware that further rewrites of the list packages may remove this funcionality again (though this is not very likely). I will write more on the subject of empty lists in a seperate e-mail message. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Mon Mar 1 20:55:05 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 20:55:05 +0100 Subject: Re: integer vector mod integer In his e-mail message of 1993/02/16, Werner Nickel writes in writing some routines to deal with integer vectors modulo a positive integer I discovered that the operation vec mod scalar in GAP 3.1 is not possible: gap> [1,2,3,4,5,6] mod 2; Error, operations: remainder of list and integer is not defined ... It would be useful to have the operation vec mod scaler available for those cases where taking the remainder makes sense. For a similar reason the operation vec mod vec for integer vectors is useful. The operation would be defined componentwise. In this way one could easily do computations in finite abelian groups. For example, adding two vectors in the group C_2 x C_4 x C_12 could be done as follows: gap> ([1,2,3] + [4,5,6]) mod [2,4,12]; [1,3,9] I never implemented this, because it didn't appear very usefull to me. But your last example is very nice (reminds me of the first program I ever worked on at the Lehrstuhl D ;-). As a matter of fact the manual for GAP 3.1 contains one example where the ability to compute ' mod ' is used (of course this example never actually worked). Expect this to come soon. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Mon Mar 1 21:30:08 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 21:30:08 +0100 Subject: Re: ranges In his e-mail message of 1993/02/24, Jean Michel writes The new ranges are an improvement, but... I find the fact that - must be divisible (the error message says divisable which is a misspelling) by to be slightly annoying. I had in my code thinks like: [1..QuoInt(n+1,2)]*2-1 to specify the odd integers smaller than n, and [1..QuoInt(n,2)]*2 to specify the even integers less than n. I hoped to be able to rewrite these as [1,3..n] and [2,4..n] but the first one works only for n odd and the second for n even! One has to use [1,3..n-1+(n mod 2)] and [2,4..n-(n mod 2)] which is less pleasant and efficient. What is the rationale for the restriction? The rationale is that a construct such as for i in [1,3..n] do ... has a visual clue that is in fact a member of the range, and that it will be the last value of . That is a programmer might (unconsciously) follow that is in the range (in the membership sense), because it is in the range literal (in a textual sense). But this visual clue could be misleading if GAP would be silently rounding, because then in the above example would be a member of the range only if it is odd. I have to admit that this is a somewhat weak argument. If one would apply it consequently, '[,..]' would also have to generate an error if ' < ', because in this case is not in the range, even though it is in the range literal. Actually, I don't really care one way or the other. If other users would also prefer silent rounding, I am quite willing to change the definition and the code accordingly (which is not a big deal). Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Mon Mar 1 21:57:07 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 1 Mar 93 21:57:07 +0100 Subject: Re: porting GAP to OS/2 2.0 with emx In his e-mail message of 1993/03/01, Harald Boegeholz writes: Sinc I just joined the GAP-forum, I don't know about "the kbhit()-problem". Could you tell me what that was? In the DOS port the function 'kbhit()' was used by GAP to poll whether the user had entered -'C'. Since this meant switching from protected mode to real mode and back, it took rather long, and since it was called quite frequently, it reduced GAP's performance significantly. How does the 'emx' version test whether the user entered -'C'? Since you write that 'emx' simulates a UNIX environment, does the extender catch the keyboard interrupt and deliver it to GAP as a signal, i.e., is 'SyAnsIntr' called if the user enters -'C'? I suggest that you upload your executable to 'samson.math.rwth-aachen.de:pub/tmp' once you feel it is ready. Then we can all experiment whether it runs not at all, slower, as fast, or faster as the current DOS version. Write me and I will set the permissions of 'pub/tmp' accordingly. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From jcbhrb@cerf.net Tue Mar 2 23:48:08 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Tue, 2 Mar 93 23:48:08 +0100 Subject: Trouble compiling gap under DOS gap-forum@samson.math.rwth-aachen.de I am having trouble compiling the source code of gap3.2 under DOS. I am using djgpp2.22 and NDMAKE4.5 . I was hoping things would be as simple as typing make "ibmpc-msdos-djgpp" in the src directory; but no such luck. Any suggestions? Jacob Hirbawi JcbHrb@CERF.net PS. I did get the executable and it's working fine; I would just like to do the compilation myself as an excercise. PPS. Apparently my e-mail last week did not go through beacuse of the disk space problem; unfortunately I didn't find that out until after I deleted it. In it I just wanted to thank Thomas Breuer for his response to my question on the direct calculation of characters and a report that gap3.2 correctly calculated the characters of the groups <2,3,3>,<2,3,4>, and <2,3,5> in a matter of minutes on a 50MHz 486; it took a little longer to do the same on an DEC 3100 Ultrix machine. From kaup@ccucvx.unican.es Wed Mar 3 10:13:09 1993 From: kaup@ccucvx.unican.es "Ansgar Kaup" Date: Wed, 3 Mar 93 10:13:09 +0100 Subject: new test for GAP 3.2 or old test valid I want to know if there is a new test like the file combinat.tst for the new GAP or is the old test valid for the new release, too. I installed GAP 3.2 in some NeXT-Stations and noticed, that the test obtains about a third part less "GAP-Stones" together with GAP-3.2. The results of our SUN didn't change so far Saludos, Ansgar From martin@bert.math.rwth-aachen.de Wed Mar 3 10:23:41 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 3 Mar 93 10:23:41 +0100 Subject: Re: new test for GAP 3.2 or old test valid The old "combinat.tst" is still valid, after all "combinat.g" didn't change. Generally 3.2 gives slightly higher GAPstones than 3.1, but not much. The exception is of course the DOS version, where 3.2 is quite a bit faster. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From fceller@bert.math.rwth-aachen.de Wed Mar 3 11:15:57 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Wed, 3 Mar 93 11:15:57 +0100 Subject: Re: new test for GAP 3.2 or old test valid >some NeXT-Stations and noticed, that the test obtains about a third part less On NeXT Station running NeXTSTEP 2.1: marvin> bin/gap-3.2 -m 4m -g -b gap> ReadTest("tst/combinat.tst"); $Id: combinat.tst,v 3.2 1992/11/25 14:49:10 martin Exp $ 18182 GAPstones This is slightly more than the reported 16484 GapStones for GAP 3.1, as expected. Both executables were compiled with GCC 2.x.y. However, if you compile GAP using CC (which is GCC 1.36) the performance will drop. best wishes Frank From DARDANO@matna.na.infn.it Wed Mar 3 14:15:24 1993 From: DARDANO@matna.na.infn.it "Ulderico Dardano" Date: Wed, 3 Mar 93 14:15:24 +0100 Subject: Mac-user looks for GAP on Mac Macintosh user(s) would be happy to run GAP on Macintosh. Can someone help them? Has someone ported GAP on Mac? If yes, how can the application be got ? I am a fresh subscriber who will aprreciate any help! thank you, ---------------------------------------------- Ulderico Dardano Dip. Matematica e Appl. RR. CaccioppoliS Monte S. Angelo T, v. Cintia, I-80126 Napoli - Italy Tel: +39 81 675713 (direct) Fax: +39 81 7662106 E-mail: dardano@matna.na.infn.it ---------------------------------------------- From caranti@volterra.cineca.it Wed Mar 3 17:08:39 1993 From: caranti@volterra.cineca.it "Andrea Caranti" Date: Wed, 3 Mar 93 17:08:39 +0100 Subject: AgGroups Dear gap-forum, consider the following piece of GAP code: ElAb := function (p) local a, b, g; a := AbstractGenerator("a"); b := AbstractGenerator("b"); g := rec( generators := [a, b], relators := [a^p, b^p] ); return AgGroupFpGroup (g); end; Now I do gap> g := ElAb (2); gap> RecFields(g); [ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs", "operations", "1", "2" ] No relators are stored in the record. GAP knows how to compute with the group g, which is a Klein four-group as expected, so gap> Comm(g.1, g.2); IdAgWord works, but why are relators not written in the record describing g? I know I can put the relators in explicitly by doing ElAb := function (p) local a, b, g, h; a := AbstractGenerator("a"); b := AbstractGenerator("b"); g := rec( generators := [a, b], relators := [a^p, b^p, Comm(a, b)] ); h := AgGroupFpGroup(g); h.relators := g.relators; return h; end; but this of course would not work when making use of the feature of omitting trivial commutator relators, as in the first version of ElAb. So my question is: why exactly are relators not (completed and) copied in these circumstances? Thank you very much in advance, yours A Caranti --------------------------------------------------------------------- A Caranti Tel ++39 461 881618 Dipartimento di Matematica Fax ++39 461 881624 Universita' degli Studi di Trento I-38050 Povo (Trento) caranti@volterra.cineca.it Italia (preferred email address. Also:) caranti@itnsp2.cineca.it caranti@itncisca.bitnet Tel ++39 461 916087 (home) From fceller@bert.math.rwth-aachen.de Wed Mar 3 17:42:52 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Wed, 3 Mar 93 17:42:52 +0100 Subject: Re: AgGroups > No relators are stored in the record. GAP knows how to compute with > the group g, which is a Klein four-group as expected, so > > gap> Comm(g.1, g.2); > IdAgWord > > works, but why are relators not written in the record describing g? I > know I can put the relators in explicitly by doing Each ag word carries a pointer to a data structure created by 'AgGroupFpGroup'. The right hand sides of all power-commutator relations are stored in this data structure , but in such a way that they need less space for non-trivial entries than the relators in abstract generators and no (extra) space for trivial entries. Creating the presentation in abstract generators would require a vast amount of space, 28 bytes for each trivial relator. best wishes Frank PS: To be precise: power-conjugates relations for single and tuple collectors and power-commutator relations for combinatorial collectors are stored in . From hwb@machnix.mathematik.uni-stuttgart.de Wed Mar 3 22:35:13 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Wed, 3 Mar 93 22:35:13 +0100 Subject: Re: new test for GAP 3.2 or old test valid Date: Wed, 3 Mar 93 10:25:54 +0100 From: martin@bert.math.rwth-aachen.de ( Martin Schoenert) Subject: Re: new test for GAP 3.2 or old test valid The old "combinat.tst" is still valid, after all "combinat.g" didn't change. Generally 3.2 gives slightly higher GAPstones than 3.1, but not much. The exception is of course the DOS version, where 3.2 is quite a bit faster. Where can I get a current copy of "combinat.tst"? I didn't find it on samson.math.rwth-aachen.de, but maybe I wasn't looking close enough. I have a copy but it seems to be outdated. Are there other tests commonly used to test GAP performance? Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From dentzer@polyhymnia.iwr.uni-heidelberg.de Thu Mar 4 15:52:59 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Thu, 4 Mar 93 15:52:59 +0100 Subject: Re: AgGroups > > > No relators are stored in the record. GAP knows how to compute with > > the group g, which is a Klein four-group as expected, so > > > > gap> Comm(g.1, g.2); > > IdAgWord > > > > works, but why are relators not written in the record describing g? I > > know I can put the relators in explicitly by doing > > Each ag word carries a pointer to a data structure created by > 'AgGroupFpGroup'. The right hand sides of all power-commutator > relations are stored in this data structure , but in such a way that > they need less space for non-trivial entries than the relators in > abstract generators and no (extra) space for trivial entries. > Creating the presentation in abstract generators would require a vast > amount of space, 28 bytes for each trivial relator. > > best wishes > Frank > > PS: To be precise: power-conjugates relations for single and tuple > collectors and power-commutator relations for combinatorial collectors > are stored in . > > But how can I see the relations of an ag group G that I read in from e.g. the library of solvable groups or the library of 2-groups? I want to find out how the generators G.1, ... correspond to the ones in a presentation of G I have in another list of solvable groups, or to correspond them to another description of G as e.g. a semidirect product, or some other extension. Ralf Dentzer P.S. Is there a function to test for isomorphism between two ag groups? This would maybe solve my problem, but I did not find such a function. Moreover this functions should also provide an isomorphism mapping generators of one group to as short as possible expressions in the generators of the second group. P.P.S What I am doing now is guessing the correspondance and verifying the relations I know, but this is rather tedious. From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar 4 16:14:06 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Thu, 4 Mar 93 16:14:06 +0100 Subject: how do I run combinat.tst? Hello! I was just trying to run combinat.tst. On my machine (RS/6000 under AIX 3.2) it fails to compute the number of GAPstones: gap> Read("combinat.tst"); Error, Variable: 'time' must have a value combinat 3.1 1992/04/29 gap> What am I doing wrong? Is there a later version of combinat.tst? Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From ahulpke@bert.math.rwth-aachen.de Thu Mar 4 16:21:41 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Thu, 4 Mar 93 16:21:41 +0100 Subject: Re: AgGroups Dear GAP-Forum, Ralf Dentzer asked, on how to obtain the presentation back from an AgGroup. The command FpGroup will create a finitely presented group from an AgGroup. The result has an entry .relators, that contains the relators of the underlying Ag presentation. (The routine basically recomputes the presentation by decomposing products and powers in the CGS). Alexander From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar 4 17:23:31 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Thu, 4 Mar 93 17:23:31 +0100 Subject: A port of GAP to OS/2 2.0 and DOS Hello! I have started porting GAP 3.2 to emx, a free software development system for OS/2 2.0 and DOS. I mainly did this because I wanted an OS/2 version of GAP, but the resulting executable should run under DOS, too. This is my first try at porting GAP, and I have spent only very little time on it. But if you need an OS/2 version or if you are curious about another DOS version, give it a try! I put the executable on ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapemx.zip Please read the enclosed documentation. Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar 4 17:30:28 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Thu, 4 Mar 93 17:30:28 +0100 Subject: how do I run combinat.tst? Sorry for the stupid question: > I was just trying to run combinat.tst. On my machine (RS/6000 under > AIX 3.2) it fails to compute the number of GAPstones: > gap> Read("combinat.tst"); > Error, Variable: 'time' must have a value > combinat 3.1 1992/04/29 gap> > What am I doing wrong? Is there a later version of combinat.tst? I have been told that I should have used ReadTest to read the test. Stupid me! Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From obrien@pell.anu.edu.au Thu Mar 4 23:35:30 1993 From: obrien@pell.anu.edu.au "Eamonn O'Brien" Date: Thu, 4 Mar 93 23:35:30 +0100 Subject: Re: AgGroups Ralf Dentzer asks > But how can I see the relations of an ag group G that I read in from > e.g. the library of solvable groups or the library of 2-groups? For groups in the 2-group or 3-group library, you access the field G.abstractRelators described on p. 571 of the manual gap> G := TwoGroup (32, 5); Group( a1, a2, a3, a4, a5 ) gap> RecFields (G); [ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs", "operations", "1", "2", "3", "4", "5", "rank", "pclass", "abstractGenerators", "abstractRelators" ] gap> G.abstractRelators; [ a1^2*a4^-1, a2^2, a2^-1*a1^-1*a2*a1*a3^-1, a3^2, a3^-1*a1^-1*a3*a1, a3^-1*a2^-1*a3*a2, a4^2*a5^-1, a4^-1*a1^-1*a4*a1, a4^-1*a2^-1*a4*a2, a4^-1*a3^-1*a4*a3, a5^2, a5^-1*a1^-1*a5*a1, a5^-1*a2^-1*a5*a2, a5^-1*a3^-1*a5*a3, a5^-1*a4^-1*a5*a4 ] gap> He also asks >P.S. Is there a function to test for isomorphism between two > ag groups? This would maybe solve my problem, but I I have implemented an algorithm which in a fair number of cases allows one to decide whether two given p-groups are isomorphic. The ANU p-Quotient Program provides access to this implementation. Part of that program is already accessible as a package in GAP 3.2. See Chapter 49 of the manual. The isomorphism testing facility is not yet accessible within GAP -- it should be available within a few months -- however, it is part of the stand-alone program. Any interested user should communicate *directly* with me on this topic. ++++++++++++++++++++++++++++++++++++++++++++++ Eamonn O'Brien ++++++++++++++++++++++++++++++++++++++++++++++ School of Mathematical Sciences Australian National University e-mail obrien@pell.anu.edu.au ++++++++++++++++++++++++++++++++++++++++++++++ From martin@bert.math.rwth-aachen.de Fri Mar 5 10:04:29 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Fri, 5 Mar 93 10:04:29 +0100 Subject: Re: Re: new test for GAP 3.2 or old test valid 'combinat.tst' is in an old message to the GAP forum, which is archived in the file 'ftp@samson.math.rwth-aachen.de:tmp/forum92d.txt'. This is version 3.1, which is still valid (except for the format of the output it hasn't changed since April 92). Currently there are no other tests, but we plan to add many more test files. Eventually we hope to cover every function in GAP with those test files. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From fceller@bert.math.rwth-aachen.de Fri Mar 5 14:54:26 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Fri, 5 Mar 93 14:54:26 +0100 Subject: Re: Re: AgGroups > Is there a function to test for isomorphism between two > ag groups? This would maybe solve my problem, but I > did not find such a function. Moreover this functions > should also provide an isomorphism mapping generators > of one group to as short as possible expressions in > the generators of the second group. How "big" are the ag groups you are interested in (composition length, size of commutator factor group)? There is a way to use 'Complements' to find isomorphisms between ag groups, but this will only work if the groups are not too big. best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Fri Mar 5 15:02:46 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Fri, 5 Mar 93 15:02:46 +0100 Subject: Re: Re: AgGroups > The command FpGroup will create a finitely presented group from an AgGroup. > The result has an entry .relators, that contains the relators of the > underlying Ag presentation. (The routine basically recomputes the > presentation by decomposing products and powers in the CGS). If the ag group is a parent with canonical generating system (this is the case if you are using 'AgGroupFpGroup') then 'FpGroup()' will construct the power-commutator presentation without collection. So, "recomputes" is slightly misleading in this case. best wishes Frank Celler From fceller@bert.math.rwth-aachen.de Fri Mar 5 15:10:42 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Fri, 5 Mar 93 15:10:42 +0100 Subject: Re: A port of GAP to OS/2 2.0 and DOS > This is my first try at porting GAP, and I have spent only very little > time on it. But if you need an OS/2 version or if you are curious > about another DOS version, give it a try! I have never used OS/2, so this might be a stupid question: Is it possible to run a fairly large GAP (say 16 mbyte job) as background process and to do some editing in the foreground on a PC 486/33Mhz with 8 mbyte of RAM under OS/2? Or is the swapping/paging to annoying? best wishes Frank Celler From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar 5 16:24:36 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Fri, 5 Mar 93 16:24:36 +0100 Subject: Re: Re: AgGroups Many thanks to all who answered my questions! The groups I am interested in are not very big, at most some hundred elements, but can be rather complicated in structure. My first problem is to recognize some groups from the literature or other computations in the complete lists of (small) solvable groups (or p-groups) contained in GAP, so that I get a complete overview of the possibilities. Some of the groups are given by relations, some as permutation groups and some as semidirect products or otherwise. The second problem is to recognize subgoups and/or factor groups of (solvable) groups in the given lists or to test isomorphism with other subgroups/factor groups. Especially the isomorphism test between subgroups should happen automatically (the groups involved in this are very small!) A further problem I am faced with is the computation of the ConjugacyClassesSubgroups(G). I didn't try this with GAP 3.2 yet, but for some groups of order 256 it took several hours with 3.1. Did these routines improve? What I am really interested in are the normal subgroups of G; is there a simpler way to compute them? (Abelian groups and groups of nilpotency class 2 can be excluded.) I intended to wait with further postings until I had taken a closer look at GAP 3.2. But as some people showed their interest in these problems I am now taking the easy way and ask the specialists for their proposals. Greetings, Ralf Dentzer dentzer@kalliope.iwr.uni-heidelberg.de From ahulpke@bert.math.rwth-aachen.de Fri Mar 5 16:50:54 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Fri, 5 Mar 93 16:50:54 +0100 Subject: Re: Re: Re: AgGroups Dear GAP-Forum, In his message, Ralf Dentzer asked: > A further problem I am faced with is the computation of the > ConjugacyClassesSubgroups(G). I didn't try this with GAP 3.2 yet, > but for some groups of order 256 it took several hours with 3.1. > Did these routines improve? What I am really interested in are > the normal subgroups of G; is there a simpler way to compute them? ConjugacyClassesSubgroups can be *very* hard (especially for p-Groups), since so many subgroups do exist. There also is a command 'NormalSubgroups', which will only compute the normal subgroups (as closures of conjugacy classes). In case the group still has lots of normal subgroups, one might also consider computing the character table, and deriving the normal subgroups from it. Alexander From hwb@machnix.mathematik.uni-stuttgart.de Fri Mar 5 17:04:26 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Fri, 5 Mar 93 17:04:26 +0100 Subject: A port of GAP to OS/2 2.0 and DOS Date: Fri, 5 Mar 93 15:13:31 +0100 Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: fceller@bert.math.rwth-aachen.de ( Frank Celler) To: Multiple recipients of list Subject: Re: A port of GAP to OS/2 2.0 and DOS > This is my first try at porting GAP, and I have spent only very little > time on it. But if you need an OS/2 version or if you are curious > about another DOS version, give it a try! I have never used OS/2, so this might be a stupid question: Is it possible to run a fairly large GAP (say 16 mbyte job) as background process and to do some editing in the foreground on a PC 486/33Mhz with 8 mbyte of RAM under OS/2? Or is the swapping/paging to annoying? I would consider 8 MByte of RAM the absolute minimum for OS/2 2.0, even without GAP. With a 16MB GAP job in the background, I think nothing would be moving at all, i.e., terrible swapping. I have 13 MBytes of RAM, and after booting OS/2 and loading a little screen saver I have about 4 MB free. So OS/2 uses at least 8 MB of RAM for itself. Your 16 MB GAP job should run ok in 16 MBytes of memory, I'd think. Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From werner@pell.anu.edu.au Mon Mar 8 01:07:49 1993 From: werner@pell.anu.edu.au "Werner Nickel" Date: Mon, 8 Mar 93 01:07:49 +0100 Subject: non-commutative Gauss algorithm Dear GAP-forum, is there a function in GAP 3.2 that takes a sequence of AG-words and applies the non-commutative Gauss algorithm to it? Checking the manual and browsing through the source code didn't reveal one. I know about the function Cgs(). Cgs() does more than I need because it also closes the generating system under conjugates/commutators and powers. The function that I have in mind just computes the `row-echelon form' for the given sequence of AG-words. With kind regards, Werner Nickel. ----------------------------/|-|--|-|--|------Werner-Nickel------------------- werner@pell.anu.edu.au /_| |\ | | | Mathematics Research Section --------------------------/--|-|-\|-|_/|------Australian-National-University-- From fceller@bert.math.rwth-aachen.de Mon Mar 8 09:02:36 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Mon, 8 Mar 93 09:02:36 +0100 Subject: Re: non-commutative Gauss algorithm Dear Werner, > is there a function in GAP 3.2 that takes a sequence of AG-words and > applies the non-commutative Gauss algorithm to it? Checking the if you need a function which converts an induced generating system of an ag group into a canonical one, you should use 'Normalize'. But there is no "non-commutative Gauss without commutator" for arbitrary set of ag words. If, however, you have a homomorphic image of an induced generating system, you could use 'HomomorphicIgs'. best wishes Frank Celler From kaup@ccucvx.unican.es Mon Mar 8 15:08:29 1993 From: kaup@ccucvx.unican.es "Ansgar Kaup" Date: Mon, 8 Mar 93 15:08:29 +0100 Subject: Degree and EuclideanDegree I gave the following commands to GAP-3.2 gap> x := X(Rationals);; x.name := "x";; gap> Degree(0*x^0); -1 gap> EuclideanDegree(0*x^0); -1 Are these answers correct ? Ansgar From fceller@bert.math.rwth-aachen.de Mon Mar 8 16:05:23 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Mon, 8 Mar 93 16:05:23 +0100 Subject: Re: Degree and EuclideanDegree Dear Ansgar, > gap> EuclideanDegree(0*x^0); > -1 > Are these answers correct ? In an euclidean ring R the euclidean degree is defined *only* for the non-zero elements of R. So one should *not* apply 'EuclideanDegree' to the zero element of an euclidean ring, the behaviour is undefined in this case. > gap> Degree(0*x^0); > -1 As there is no "-infty", -1 is used. This is convenient in polynomial rings and hopefully not too confusing in laurent polynomial rings. best wishes Frank From sibley@math.psu.edu Mon Mar 8 19:54:52 1993 From: sibley@math.psu.edu "David Sibley" Date: Mon, 8 Mar 93 19:54:52 +0100 Subject: Where 3.2? I must have missed the announcement. People here have been discussing GAP 3.2 for quite a while now, but I can't find it at dimacs.rutgers.edu, where I got previous versions. Where can I get it? David Sibley NT3O sibley@math.psu.edu From martin@bert.math.rwth-aachen.de Mon Mar 8 20:01:54 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 8 Mar 93 20:01:54 +0100 Subject: Re: Where 3.2? Is 'dimacs.rutgers.edu' still not up to date? Sorry about that. The closest server for you is probably 'wuarchive.wustl.edu'. There you find GAP in the directory '/edu/math/source.code/group.theory/gap'. 'wuarchive' should never be more than a day behind 'samson.math.rwth-aachen.de', because the automatically retrieve all new files every night. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From jcbhrb@cerf.net Mon Mar 8 22:57:53 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Mon, 8 Mar 93 22:57:53 +0100 Subject: RE: Trouble compiling GAP under DOS gap-forum@samson.math.rwth-aachen.de In regards to my question last week about compiling gap under DOS; first the bad news: I could not resolve the problems I was having with the 'make' utility in spite of the help I received from Martin. The good news is that I managed to produce an executable by other means -- not as nice as using the standard Makefile but at least I got this to work: (1) compile the DOS specific subroutine gcc -c sysdos.c -DSYS_IS_MSDOS (2) compile the system independant subroutines gcc -c vecffe.c gcc -c word.c gcc -c vector.c gcc -c unknown.c gcc -c tietze.c gcc -c string.c gcc -c set.c gcc -c statemen.c gcc -c record.c gcc -c scanner.c gcc -c rational.c gcc -c read.c gcc -c polynom.c gcc -c range.c gcc -c permutat.c gcc -c plist.c gcc -c pcpresen.c gcc -c list.c gcc -c integer.c gcc -c gasman.c gcc -c idents.c gcc -c function.c gcc -c finfield.c gcc -c cyclotom.c gcc -c eval.c gcc -c blister.c gcc -c costab.c gcc -c aggroup.c gcc -c agcollec.c (3) compile the main program (also system independant) gcc -c gap.c (4) archive the object files of all subroutines into a "gaplib.a" archive ar -cr gaplib.a sysdos.o ar -cr gaplib.a set.o ar -cr gaplib.a word.o ar -cr gaplib.a agcollec.o ar -cr gaplib.a aggroup.o ar -cr gaplib.a costab.o ar -cr gaplib.a blister.o ar -cr gaplib.a eval.o ar -cr gaplib.a cyclotom.o ar -cr gaplib.a finfield.o ar -cr gaplib.a function.o ar -cr gaplib.a idents.o ar -cr gaplib.a gasman.o ar -cr gaplib.a integer.o ar -cr gaplib.a list.o ar -cr gaplib.a pcpresen.o ar -cr gaplib.a plist.o ar -cr gaplib.a permutat.o ar -cr gaplib.a range.o ar -cr gaplib.a polynom.o ar -cr gaplib.a read.o ar -cr gaplib.a rational.o ar -cr gaplib.a scanner.o ar -cr gaplib.a record.o ar -cr gaplib.a statemen.o ar -cr gaplib.a string.o ar -cr gaplib.a tietze.o ar -cr gaplib.a unknown.o ar -cr gaplib.a vector.o ar -cr gaplib.a vecffe.o ranlib gaplib.a (5) produce the executable and add the DOS extender part gcc -o mygap gap.o gaplib.a -lpc aout2exe mygap The final result is mygap.exe which should be the functional equivalent of the standard gap.exe. This is probably more detail than most would care to know but hopefully this will be of some help since these commands can be collected into one batch file without worrying about command line length restrictions and the like; The executable seems to be working fine. Now I have to figure out why it is a full 150KByes bigger than the standard gap.exe! Jacob Hirbawi JcbHrb@CERF.net From martin@bert.math.rwth-aachen.de Mon Mar 8 23:11:10 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 8 Mar 93 23:11:10 +0100 Subject: Re: RE: Trouble compiling GAP under DOS Jacob Hirbawi writes in his e-mail message of 1993/03/08 In regards to my question last week about compiling gap under DOS; first the bad news: I could not resolve the problems I was having with the 'make' utility in spite of the help I received from Martin. The good news is that I managed to produce an executable by other means -- not as nice as using the standard Makefile but at least I got this to work: (1) compile the DOS specific subroutine gcc -c sysdos.c -DSYS_IS_MSDOS (2) compile the system independant subroutines gcc -c vecffe.c gcc -c word.c gcc -c vector.c gcc -c unknown.c [similar commands for the other source files] (5) produce the executable and add the DOS extender part gcc -o mygap gap.o gaplib.a -lpc aout2exe mygap The final result is mygap.exe which should be the functional equivalent of the standard gap.exe. This is probably more detail than most would care to know but hopefully this will be of some help since these commands can be collected into one batch file without worrying about command line length restrictions and the like; The executable seems to be working fine. Now I have to figure out why it is a full 150KByes bigger than the standard gap.exe! I think the reason that your executable is larger than ours is that we use the optimizing option '-O2' of 'gcc'. This tends to decrease the size of the executable (and it makes the executable faster too). If you do this your executable should even be a little bit smaller than ours, because we prepend the whole DOS extender to the executable while 'aout2exe' only adds a stub that loads the DOS extender at run time. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From short@jordan.csu.murdoch.edu.au Tue Mar 9 04:51:58 1993 From: short@jordan.csu.murdoch.edu.au "Mark Short" Date: Tue, 9 Mar 93 04:51:58 +0100 Subject: Recognising small groups Ralf Dentzer writes (in part): > The groups I am interested in are not very big, at most some hundred > elements, but can be rather complicated in structure. > My first problem is to recognize some groups from the literature or other > computations in the complete lists of (small) solvable groups (or > p-groups) contained in GAP, so that I get a complete overview of > the possibilities. Some of the groups are given by relations, some > as permutation groups and some as semidirect products or otherwise. > > The second problem is to recognize subgoups and/or factor groups of > (solvable) groups in the given lists or to test isomorphism with > other subgroups/factor groups. Especially the isomorphism test > between subgroups should happen automatically (the groups involved > in this are very small!) The good news: I have code that recognises many ``small'' groups. For example, if given GL(2,3) in any form, then (assuming any coset enumerations that might be needed can be accomplished, and so on) it would return something like this: Order: 48 Identifier: 48.49 Name: GL(2,3) I won't bother to describe any more details because of the following items of bad news: 1. The code is written in Cayley. GAP didn't have all the features I needed when I first started the project in 1987. I think GAP has all the necessary features now, but the code comprises 3000 lines, so I am in no hurry to make the conversion! So, if you can be bothered you might want to make part of this conversion yourself. 2. My identifiers for the groups are usually not those used by GAP. For example, the group A_4 would come back as Order: 12 Identifier: p^2q # 2g Name: A(4) (This is because an analogue of A_4 exists for many orders p^2q (where p and q are distinct primes) and my code can recognise any such group.) If your group has a name, then this is no problem, but if it doesn't, then you just get an identifier, which of course is no help in recognising the group unless you know my classification scheme! ----- So Ralf, yes I can help you, but only if you are willing to put in a significant amount of work! If you want any more details please write to me directly at short@jordan.csu.murdoch.edu.au My apologies to other readers for going on about non-GAP issues. Mark Short Murdoch University Western Australia From short@jordan.csu.murdoch.edu.au Tue Mar 9 06:03:03 1993 From: short@jordan.csu.murdoch.edu.au "Mark Short" Date: Tue, 9 Mar 93 06:03:03 +0100 Subject: correction A minor correction to my reply to Ralf Dentzer: I wrote ``GAP didn't have all the features I needed when I first started the project in 1987.'' I now recall that I didn't even know of GAP's existence until 1989! From obrien@pell.anu.edu.au Tue Mar 9 07:18:35 1993 From: obrien@pell.anu.edu.au "Eamonn O'Brien" Date: Tue, 9 Mar 93 07:18:35 +0100 Subject: A second GAP forum? I write to pose the question -- Is it appropriate to establish two GAP forums? Should we have -- one to deal with mathematical queries, uses of GAP to solve particular problems, bug reports, etc. -- one to deal with machine specific items such as porting, compiliation, performance of standard tests, distribution of executables, etc. The amount of correspondence generated by the GAP forum has grown significantly over the past few months; much of it seems to be of the second type and I'm one of those who is primarily interested in the first. I realise that on occasion it will be difficult to determine the appropriate forum for a posting -- in such circumstances, I'm sure we will not object to people posting to both groups -- however, most recent postings seem to pose no difficulty in this respect. As a regular user of GAP, I think the forum serves a very useful role and it is in that vein that I raise this query. I'm interested in other subscriber opinions on this matter. ++++++++++++++++++++++++++++++++++++++++++++++ Eamonn O'Brien ++++++++++++++++++++++++++++++++++++++++++++++ School of Mathematical Sciences Australian National University e-mail obrien@pell.anu.edu.au ++++++++++++++++++++++++++++++++++++++++++++++ From werner@pell.anu.edu.au Tue Mar 9 08:56:40 1993 From: werner@pell.anu.edu.au "Werner Nickel" Date: Tue, 9 Mar 93 08:56:40 +0100 Subject: Re: A second GAP forum? Dear GAP forum, I thought it might be useful to get some statistics about the postings to the GAP forum. Eamonn O'Brien asks if the GAP forum should be split into two forums. I went through all the postings to the GAP forum that were sent since the beginning of this year and put them into the two categories that Eamonn suggests. I counted a total of 127 postings (discarding meaningless postings like the error messages about someone's full hard disk, etc.). 72 postings would qualify for the first category (mathematical issues, etc.) of postings, 55 for the second category (implementation issues, etc.). There were 70 postings before GAP 3.2 was released. 45 of those would go into the first category and only 25 into the second. Since the release of GAP 3.2 there were 57 postings, 27 of which belong to the first category and 30 to the second category. The distribution of postings before and after the release of GAP 3.2 is interesting. I think that what we are seeing here is an increase of postings of the second category because there was a new release of GAP and people have to sort out the various installation problems. Also, it is after a new release has become available that people are interested in performance questions and compare the old to the new release. Therefore, I expect that the number of postings of the second category will decrease during the next weeks. My opinion is that the volume of the GAP-forum is acceptable and that there is no need to split the forum. Furthermore, I usually find it easy to recognize `uninteresting' messages from the subject line. If people continue to use keywords (like permutation group problem, performance, compiling, DOS, etc.) as part of their subject that indicate the nature of their posting, there should not be a problem in sifting out those messages which deal with issues of the first category. Regards, Werner Nickel. ----------------------------/|-|--|-|--|------Werner-Nickel------------------- werner@pell.anu.edu.au /_| |\ | | | Mathematics Research Section --------------------------/--|-|-\|-|_/|------Australian-National-University-- From short@jordan.csu.murdoch.edu.au Wed Mar 10 01:22:50 1993 From: short@jordan.csu.murdoch.edu.au "Mark Short" Date: Wed, 10 Mar 93 01:22:50 +0100 Subject: Re: A second GAP forum? I wish to register my support for Eamonn O'Brien's recent suggestion that there be two GAP forums. I too am primarily interested in postings that fit into his first category and would prefer not to receive postings that fit into his second category. Mark Short Mathematics Programme Murdoch University Western Australia From MATHURLEY@bodkin.ucg.ie Wed Mar 10 10:33:38 1993 From: MATHURLEY@bodkin.ucg.ie "Ted Hurley" Date: Wed, 10 Mar 93 10:33:38 +0100 Subject: Groups93 Galway/St-Andrews As many readers of this list may know, an international conference on Group Theory (GROUPS 1993 Galway/St. Andrews) will be held at University College Galway from 1-14 August 1993. Short courses will be given by J. Alperin (Chicago), M Broue (Paris), A. Lubotzky (Jerusalem), P. Kropholler (QMW, London) and E. Zel'manov (Wisconsin). A workshop on *Computational Group Theory using GAP* will be conducted by J. Neubueser (Aachen) and Martin Schoenert (Aachen). It is hoped to conduct workshops to suit all levels of expertize. Further information and application form may be obtained by writing to: Groups 93, Department of Mathematics, University College, Galway, Ireland or by e-mail: matward@bodkin.ucg.ie or groups93@dcs.st-andrews.ac.uk The organizers wish to know approximate numbers participating so that the necessary resources can be put in place, and are asking those who have not already registered, to do so as soon as possible. From DARDANO@matna.na.infn.it Wed Mar 10 14:21:34 1993 From: DARDANO@matna.na.infn.it "Ulderico Dardano" Date: Wed, 10 Mar 93 14:21:34 +0100 Subject: RE: A second GAP forum? I think that the idea in itself of making (some) sub-forum's should be considered. I actually find that the amount of messages which I don't find interesting (for me! of course) is large enough and hope that in future it will increase .... ciao Ulderico ---------------------------------------------- Ulderico Dardano Dip. Matematica e Appl. "R. Caccioppoli" Monte S. Angelo T, v. Cintia, I-80126 Napoli - Italy Tel: +39 81 675713 (direct) Fax: +39 81 7662106 E-mail: dardano@matna.na.infn.it ---------------------------------------------- From am@ime.usp.br Wed Mar 10 16:17:41 1993 From: am@ime.usp.br "Arnaldo Mandel" Date: Wed, 10 Mar 93 16:17:41 +0100 Subject: RE: A second GAP forum? I propose a third gap forum, which would be dedicated to the proposal of new gap forums. ................................................................. Arnaldo Mandel \ am@ime.usp.br (1st choice) Computer Science Dep. \ amandel@cce.usp.br (2nd) Universidade de S\~{a}o Paulo / mac@fpspux.fapesp.br S\~{a}o Paulo - SP - Brazil / (if all else fails) From martin@bert.math.rwth-aachen.de Wed Mar 10 16:34:23 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 10 Mar 93 16:34:23 +0100 Subject: Re: A second GAP forum? I would like to argue against splitting the GAP forum for some practical reasons. If I look at the log of the listserver, I see that a large number of messages (especially messages asking for help in installing GAP or asking about possible bugs in GAP) are sent by subscribers who have only shortly before subscribed. Those users will usually not be aware of the etiquette of the GAP forum, especially since the README file says nothing about two GAP forums. Thus I doubt that the splitting will be effective for messages from such new subscribers. Like Werner I expect that the amount of messages related to distribution, installation, porting, etc. will decrease once everybody has got GAP 3.2. Then most of the messages should again be mathematical queries (hopefully not bug reports ;-). The number of messages in the GAP forum is not that high, though I admit that it has been steadily increasing. Also the subject lines are usually quite informative, which makes it rather easy to kill uninteresting messages. I would however suggest the following. Discussions, such as the discussion about GAP for OS/2 should, after the initial message, be carried out by e-mail rather than in the GAP forum. (I admit that I am such an offender myself and promise to use e-mail rather than the GAP forum more often in the future ;-) We write a FAQ (frequently asked questions with answers), containing everybodies favorite question such as "Is there a version of GAP for the Macintosh". This would be posted every two weeks and also e-mailed automatically to new subscribers. We could mandate a standard format for the subject line. E.g., "Does GAP run on ?" "Installation Problem on " "Bug in ?" then users with sufficiently intelligent mail readers can filter out uninteresting stuff automatically. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From hwb@machnix.mathematik.uni-stuttgart.de Thu Mar 11 15:29:41 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Thu, 11 Mar 93 15:29:41 +0100 Subject: new GAP for OS/2 with hypertext documentation Hello! I have made available a slightly updated version of my OS/2 port of GAP 3.2. It is in ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapemx.zip. I have also created a hypertext version of the GAP documentation for use with OS/2's IPF (Information Presentation Facility). Since this file is pretty big (700k compressed), I put it in a separate archive: ftp.uni-stuttgart.de:/soft/os2/ProgLang/Languages/gapinf.zip. Enjoy! Harald -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From dentzer@polyhymnia.iwr.uni-heidelberg.de Thu Mar 11 16:02:17 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Thu, 11 Mar 93 16:02:17 +0100 Subject: SemidirectProduct It seems to me that for semidirect products of AG groups the operations Embedding and Projection are not implemented. (For permutation groups they seem to work.) Here is an example: gap> G:=AllSolvableGroups(Size, 64)[249]; grp_64_249 gap> N:=Subgroup(G, [G.1, G.4, G.5, G.6]); Subgroup( grp_64_249, [ a, d, e, f ] ) gap> B:=Subgroup(G, [G.2]); Subgroup( grp_64_249, [ b ] ) gap> phi:=IdentityMapping(B); IdentityMapping( Subgroup( grp_64_249, [ b ] ) ) gap> GG:=SemidirectProduct(B, phi, N); Group( g1, g2, g3, g4, h1, h2, h3, h4 ) gap> Embedding(B, GG, 1); Error, Record: element 'Embedding' must have an assigned value at return arg[2].operations.Embedding( arg[1], arg[2], arg[3] ) ... in Embedding( B, GG, 1 ) called from main loop brk> quit; gap> Projection(GG, B, 1); Error, Record: element 'Projection' must have an assigned value at return arg[1].operations.Projection( arg[1], arg[2], arg[3] ) ... in Projection( GG, B, 1 ) called from main loop brk> quit; As a workaround I use GG.embeddings resp. GG.projections. Ralf Dentzer dentzer@kalliope.iwr.uni-heidelberg.de From dlj@maths.nott.ac.uk Thu Mar 11 16:10:17 1993 From: dlj@maths.nott.ac.uk "Dr D. L. Johnson" Date: Thu, 11 Mar 93 16:10:17 +0100 Subject: Re: A second GAP forum? This is to second Dr.O'Brien's suggestion. Dave Johnson From am@ime.usp.br Thu Mar 11 16:18:57 1993 From: am@ime.usp.br "Arnaldo Mandel" Date: Thu, 11 Mar 93 16:18:57 +0100 Subject: RE: new GAP for OS/2 with hypertext documentation Harald Boegeholz writes: > > I have also created a hypertext version of the GAP documentation for > use with OS/2's IPF (Information Presentation Facility). Since this > file is pretty big (700k compressed), I put it in a separate archive: One of the things I miss on GAP is good online documentation, fur the unix environment implementation. My favorite choice would be an Emacs info document, although I can survive other formats which allow fast online search (thus, havin the manual online as a .dvi or .ps file will not cut it). Is there any hope that such a thing will ever appear? Maybe this IPF hypertext can be ported. Arnaldo ................................................................. Arnaldo Mandel \ am@ime.usp.br (1st choice) Computer Science Dep. \ amandel@cce.usp.br (2nd) Universidade de S\~{a}o Paulo / mac@fpspux.fapesp.br S\~{a}o Paulo - SP - Brazil / (if all else fails) From fceller@bert.math.rwth-aachen.de Thu Mar 11 16:27:03 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Thu, 11 Mar 93 16:27:03 +0100 Subject: Re: SemidirectProduct > As a workaround I use GG.embeddings resp. GG.projections. The embeddings and projections are bound to .embeddings and .projections but there is no 'SemidirectProductAgGroupOps' operations record at the moment, so that 'Projection' and 'Embedding' will indeed not work. best wishes Frank Celler From sibley@math.psu.edu Thu Mar 11 16:49:11 1993 From: sibley@math.psu.edu "David Sibley" Date: Thu, 11 Mar 93 16:49:11 +0100 Subject: conjugacy class recognition problem I'm trying to do something with conjugacy classes in AgGroups. This is in 3.1. I still don't have 3.2 (wustl seems to be VERY busy). If this is fixed in 3.2, please let me know. Here is a very simple example. gap> g:=TwoGroup(8,4);; gap> ConjugacyClasses(g);; gap> t:=ConjugacyClass(g,g.3); ConjugacyClass( Group( a1, a2, a3 ), a3 ) gap> g.conjugacyClasses[2]; ConjugacyClass( Group( a1, a2, a3 ), a3 ) gap> t = g.conjugacyClasses[2]; false gap> Position(g.conjugacyClasses,t); false gap> The point is that it doesn't recognize that the two classes are the same, nor does it even recognize that the class generated by ConjugacyClass is a class (in the list g.conjugacyClasses) at all. From fceller@bert.math.rwth-aachen.de Thu Mar 11 16:58:36 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Thu, 11 Mar 93 16:58:36 +0100 Subject: Re: conjugacy class recognition problem > The point is that it doesn't recognize that the two classes are the > same, nor does it even recognize that the class generated by > ConjugacyClass is a class (in the list g.conjugacyClasses) at all. This is bug in 3.1 which is fixed in 3.2: gap> g:=TwoGroup(8,4);; gap> ConjugacyClasses(g);; gap> t:=ConjugacyClass(g,g.3); ConjugacyClass( Group( a1, a2, a3 ), a3 ) gap> g.conjugacyClasses[2]; ConjugacyClass( Group( a1, a2, a3 ), a3 ) gap> t = g.conjugacyClasses[2]; true gap> Position(g.conjugacyClasses,t); 2 gap> VERSION; "Version 3 Release 2" best wishes Frank Celler From dennis@math.cornell.edu Thu Mar 11 17:04:32 1993 From: dennis@math.cornell.edu "Keith Dennis" Date: Thu, 11 Mar 93 17:04:32 +0100 Subject: RE: new GAP for OS/2 with hypertext documentation Arnaldo Mandel (am@ime.usp.br) writes >One of the things I miss on GAP is good online documentation, fur the >unix environment implementation. My favorite choice would be an Emacs >info document, although I can survive other formats which allow fast >online search (thus, havin the manual online as a .dvi or .ps file >will not cut it). Is there any hope that such a thing will ever >appear? Maybe this IPF hypertext can be ported. The previewer from ArborText does searches on strings of ordinary characters in a dvi file (unfortunately, no accented characters or math is accepted). Thus you can preview dvi files AND search them. The previewer can be bought separately (about $375 educational price). It is also available as one of the pieces of Publisher if you happen to already own it. Keith Dennis From sibley@math.psu.edu Thu Mar 11 17:14:27 1993 From: sibley@math.psu.edu "David Sibley" Date: Thu, 11 Mar 93 17:14:27 +0100 Subject: RE: new GAP for OS/2 with hypertext documentation > >One of the things I miss on GAP is good online documentation, fur the >unix environment implementation. My favorite choice would be an Emacs >info document, although I can survive other formats which allow fast >online search (thus, havin the manual online as a .dvi or .ps file >will not cut it). Is there any hope that such a thing will ever >appear? Maybe this IPF hypertext can be ported. Eh? I find the GAP online documentation to be excellent. It's much faster and more efficient than anything I ever experienced with EMACS info files, where you have to know where an item is in the heirarchy. But maybe we are talking about different things. I'm referring to the "?" and "??" runtime help facilities. You can even read the manual page by page using "?>". These are extremely powerful utilities. I find them much better than EMACS info files. Perhaps you have not investigated thoroughly what can be done with these. From schumach@math.wisc.edu Thu Mar 11 19:04:06 1993 From: schumach@math.wisc.edu "Lee Schumacher" Date: Thu, 11 Mar 93 19:04:06 +0100 Subject: Re: new GAP for OS/2 with hypertext documentation >>One of the things I miss on GAP is good online documentation, fur the >>unix environment implementation. My favorite choice would be an Emacs >>info document, although I can survive other formats which allow fast >>online search (thus, havin the manual online as a .dvi or .ps file >>will not cut it). Is there any hope that such a thing will ever >>appear? Maybe this IPF hypertext can be ported. > >Eh? I find the GAP online documentation to be excellent. It's much >faster and more efficient than anything I ever experienced with EMACS >info files, where you have to know where an item is in the heirarchy. > >But maybe we are talking about different things. I'm referring to the >"?" and "??" runtime help facilities. You can even read the >manual page by page using "?>". These are extremely powerful utilities. >I find them much better than EMACS info files. Perhaps you have not >investigated thoroughly what can be done with these. The ? and ?? are quite useful, its true, but hardly a substitute for a real structured info tree. The problem with the GAP facilities is that you need to know the NAME of the function or concept before you can find it. Of course the topic of discourse in GAP is sufficiently narrow that this is not a problem in general. However I did read the manual off line first and now ? is useful more as a memory jogger. Note that emacs info files are intended more for learing new concepts and groups of commands or functions. If you just want to find a command and you have a pretty good idea what the name is then you use apropos, which provides all of the functionality of ? and ??. Lee From sibley@math.psu.edu Thu Mar 11 20:23:44 1993 From: sibley@math.psu.edu "David Sibley" Date: Thu, 11 Mar 93 20:23:44 +0100 Subject: Re: new GAP for OS/2 with hypertext documentation >The ? and ?? are quite useful, its true, but hardly a substitute for a >real structured info tree. The problem with the GAP facilities is >that you need to know the NAME of the function or concept before you >can find it. [rest deleted] Not so. Something like "??conjug" will give you a list of all references involving conjugation, conjugacy, conjugate, etc. I use the ?? utility this way a lot. The reference name need not even involve the letters "conjug", since many references have short descriptions associated with them which involve other words and which are found by the ?? command. Nor do you have to get the case correct, as ?? is not case sensitive. Yes, you do have to know something about what you are looking for, but certainly not the exact name. Yes, it is very much like "apropos". Yes, to use the ? you need the exact name (except case does not matter, and actually you need only a unique initial string from the name -- the tab-key name-completion feature will help with this if you bother to type the cases right). You can easily get the correct name from a ?? query. Well, yes, sometimes there are several likely-looking names, so I check them all. I find this a lot easier than following several likely-looking branches in an info tree. From am@ime.usp.br Thu Mar 11 21:48:08 1993 From: am@ime.usp.br "Arnaldo Mandel" Date: Thu, 11 Mar 93 21:48:08 +0100 Subject: Re: new GAP for OS/2 with hypertext documentation This discussion is getting a bit out of hand. I said some time ago: >> One of the things I miss on GAP is good online documentation, fur the >> unix environment implementation. My favorite choice would be an Emacs ^^^^^^^^^^^^^^^^^^ >> info document, although I can survive other formats which allow fast There were some suggestions and some discussion, and then David Sibley pointed out: > > Yes, to use the ? you need the exact name (except case does not matter, > and actually you need only a unique initial string from the name -- the > tab-key name-completion feature will help with this if you bother to > type the cases right). You can easily get the correct name from a ?? > query. Well, yes, sometimes there are several likely-looking names, so > I check them all. I find this a lot easier than following several ^^^^^^^^^^^^^^^^^^^^^^^^ > likely-looking branches in an info tree. I don't. But the whole discussion is boiling down to a matter of personal preferences. Since I live most of the time within emacs, and maintain it here, it is perhaps natural that I have become addicted to info. On the other hand, I will retract my complaints about lack of "good online documentation" (I had no intention of putting down ? and ??), and qualify it instead as a "lack of an online manual of the kind *I* find convenient". Now, perhaps I would have kept to myself about info, if it wasn't for the circunstance that a hypertext version of GAP documentation had been created, for another plataform. The source code for GAP shows that emacs was a heavily used tool for development; maybe the developers of GAP would have something to say on this matter. Anyway, it is not such a big deal. ................................................................. Arnaldo Mandel \ am@ime.usp.br (1st choice) Computer Science Dep. \ amandel@cce.usp.br (2nd) Universidade de S\~{a}o Paulo / mac@fpspux.fapesp.br S\~{a}o Paulo - SP - Brazil / (if all else fails) From neubuese@samson.math.rwth-aachen.de Fri Mar 12 09:28:22 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Fri, 12 Mar 93 09:28:22 +0100 Subject: Comfort in GAP Dear GAP-forum, In his last letter Arnaldo Mandel asks that the developers of GAP should comment on the discussion about online documentation for GAP. Rather than leaving a technical contribution on this problem to those who have done the actual work in the development that is there, as the oldest in the team I want to make a general statement: Please do not forget in such discussions about the wanted comfort in the use of GAP (the discussion on the splitting of the gap-forum and a few others were in the same line) that GAP is developed by a small group of mathematicians ("Lehrstuhl" means chair, and this is a correct description, there is one chair in mathematics and some assistants and several students around it who are developing the central part of GAP). This is what I have tried to emphazise in the preface to the manual, GAP is thought of as an open system to which, we hope, other people will also contribute mathematics, it is not a commercial product where you can demand and buy the personal comfort that you personally would prefer. We have volunteered to provide some reasonable environment for using GAP and in particular several of my young colleagues and students have devoted quite a bit of time (that often enough is hardly recognized as doing mathematics in academic proceedings) to these developments. We do not regret this or want to complain now, but I just ask everybody's understanding that we do have priorities that tend more to implementing new mathematics than fulfilling every possible (even if quite understandable and justified) wish for more comfort. We are most grateful to those colleagues who have on their own taken up some of the more technical tasks in making GAP available or more comfortable to use, for instance to Steve Linton for doing the first portation to the DOS world, to Professor Mendelsohn's group for making GAP available on MACs or to Harald Boegeholz for providing a hypertext version to name just some. And we welcome of course very much the "share libraries" that add to its mathematical power. We think that GAP can survive as an open system only if also some of the technical tasks are shared by some more people than the few at Aachen and we ask you to further help us in this way. These tasks should be discussed in the gap-forum as well as - I hope increasingly again - mathematics that has been done or can be done with GAP and I think that it is not too much of a burden to throw away those e-mails that do not concern you. A small special request in this line: please try to get the latest version of GAP and to follow up the patches that are made available in some intervals; as in every larger system there are of course bugs in GAP but quite often we do get reports on bugs that have already been fixed and for which the fix had been distributed. Finding this out does take some time that you could help us to save by having all bug-fixes installed with you at the earliest possible time. Thank you for your understanding for these matters. Joachim Neubueser From bro@clio.iwr.uni-heidelberg.de Fri Mar 12 10:37:30 1993 From: bro@clio.iwr.uni-heidelberg.de "Karl Brodowsky" Date: Fri, 12 Mar 93 10:37:30 +0100 Subject: RE: new GAP for OS/2 with hypertext documentation emtex has a dvi-previewer which enables searching and which is FREE. Running on OS-Half and on MS-dos. From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar 12 11:13:53 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Fri, 12 Mar 93 11:13:53 +0100 Subject: FrattiniSubgroup The GAP function FrattiniSubgroup is not included in the manual. I think this is due to the fact that it only works for p-groups. Can I hope for this function to work for general AG groups or even all finite groups sometime? (I had some hopes that this would be included in version 3.2.) At the moment I can compute the frattini subgroup by brute force using ConjugacyClassesSubgroups, but is there a better way? (And should this brute force method be included in GAP?) Regards Ralf Dentzer dentzer@kalliope.iwr.uni-heidelberg.de From neubuese@samson.math.rwth-aachen.de Fri Mar 12 13:31:42 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Fri, 12 Mar 93 13:31:42 +0100 Subject: Re: FrattiniSubgroup Ralf Dentzer asks: > The GAP function FrattiniSubgroup is not included in the manual. > I think this is due to the fact that it only works for p-groups. > Can I hope for this function to work for general AG groups > or even all finite groups sometime? This function FrattiniSubgroup(G) does in fact exist, and it works only for p-groups which moreover must be given as AG-groups - it will not work for a p-group that is given by generating permutations for instance. The reason that it is not included in the manual (and possibly extended by a brute force method in all other cases) is the following: Charles Leedham-Green has proposed the use of a very special kind of AG-presentations for arbitrary soluble groups which among other things will facilitate the computation of all maximal subgroups of a soluble group and hence of course also the Frattini subgroup. A student here in Aachen, Bettina Eick, is at present implementing this and related proposals and we hope that with the next release of GAP her programs which indeed will give some further new functions and some improvements of performnce for some existing ones will be included. At that time then we shall try to have a general function FrattiniGroup which in the cases where we do not know better will resort to brute force. Ralf Dentzer continues: > (I had some hopes that this would be included in version 3.2.) Me too! > At the moment I can compute the frattini subgroup by brute force > using ConjugacyClassesSubgroups, but is there a better way? > (And should this brute force method be included in GAP?) See above. Thanks for the question, we are happy to inform about what is going on and encourage others to do the same with work going on with them. Joachim Neubueser neubueser@math.rwth-aachen.de From dentzer@polyhymnia.iwr.uni-heidelberg.de Fri Mar 12 14:31:41 1993 From: dentzer@polyhymnia.iwr.uni-heidelberg.de "Ralf Dentzer" Date: Fri, 12 Mar 93 14:31:41 +0100 Subject: ConjugacyClassesSubgroups Under certain conditions the function ConjugacyClassesSubgroups doesn't seem to work correctly. I have a subgroup U of a parent group G with the following RecFields: gap> RecFields(U); [ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "parent", "operations", "size", "cgs", "zuppoBlist", "isFinite", "shiftInfo", "normalizer", "isAbelian", "elements", "zuppos", "trivialSubgroup", "generatorZuppoBlist", "perfectSubgroups" ] gap> RecFields(G); [ "generators", "identity", "isDomain", "isGroup", "isAgGroup", "cgs", "operations", "1", "2", "3", "4", "5", "name", "isAbelian", "elements", "zuppos", "zuppo_generators", "zuppo_powers", "zuppo_primes", "zuppo_exponents", "trivialSubgroup", "size", "generatorZuppoBlist", "perfectSubgroups", "zuppoBlist", "compositionSeries", "elementaryAbelianFactors", "isSolvable", "elementaryAbelianSeries", "index", "isFinite", "shiftInfo", "generatorZuppos", "lattice", "conjugacyClassesSubgroups", "isNormal", "factorGroup", "conjugacyClasses", "normalClosure", "normalSubgroups" ] and I get the following error: gap> ConjugacyClassesSubgroups(U); Error, Record: element 'zuppo_powers' must have an assigned value at if G.zuppo_powers[pos] = false or hzup[G.zuppo_powers[pos]] ... in H.representative.operations.SetLatticeStatus( L, H, status ) called from SetLatticeStatus( L, C, L.classGroups ) called from obj.operations.Lattice( obj ) called from Lattice( G ) called from G.operations.ConjugacyClassesSubgroups( G ) called from .. The function works properly if I call it with gap> ConjugacyClassesSubgroups(Group(U)); In case you are interested: G = grp_32_40 and U = Subgroup( G, [G.1, G.2, G.4, G.5]). Best regards Ralf Dentzer From neubuese@samson.math.rwth-aachen.de Fri Mar 12 15:14:09 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Fri, 12 Mar 93 15:14:09 +0100 Subject: Re: ConjugacyClassesSubgroups Ralf Dentzer reports: > Under certain conditions the function ConjugacyClassesSubgroups doesn't > seem to work correctly. I have a ........ Thanks for the warning, we will look at the problem and hopefully provide a fix with the first patch to be distributed "soon". Joachim Neubueser From martin@bert.math.rwth-aachen.de Fri Mar 12 17:18:13 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Fri, 12 Mar 93 17:18:13 +0100 Subject: Re: RE: new GAP for OS/2 with hypertext documentation Arnaldo Mandel writes in his e-mail message of 1993/03/11 One of the things I miss on GAP is good online documentation, fur the unix environment implementation. My favorite choice would be an Emacs info document, although I can survive other formats which allow fast online search (thus, havin the manual online as a .dvi or .ps file will not cut it). Is there any hope that such a thing will ever appear? Maybe this IPF hypertext can be ported. I would like to know which features of GNU EMACS' info mode you miss in GAP's on-line help. I think that both allow roughly the same. 1) You know exactly what you are looking for: In EMACS you use 'g '. In GAP you use '?'. 2) You know roughly what you are looking for: In EMACS you go to one of the indices (say with 'g concept index'), find the most likely candidate and with 'm ' you go there. In GAP you use '??', select the most likely candidate and with '?' you go there. 3) You want to browse around in the manual: In EMACS you go to the top node, select a section and go there with 'm

'. In the section you again use 'm ' to go to the next subsection. In GAP you say '?chapters', select a chapter and go there with '?'. Then you read the first section of the chapter and find references (of the form (see "
")) to all the sections in this chapter. Then you again use '?
' to go to the section you are interested in. 4) You want to go to the next or previous node/section: In EMACS you use 'n' and 'p'. In GAP you use '?>' and '?<'. 5) You want to go from a subsection to a section: In EMACS you use 'u'. In GAP you use '?<<'. 6) You want to go from a subsection to the next node section: In EMACS you use 'u' and 'n'. In GAP you use '?>>'. 7) You want to follow a cross reference. In EMACS you use 'f '. In GAP cross references are again of the form (see "
") and you use '?
'. 8) You want to go to the last section that you visited before the current one: In EMACS you use 'l'. In GAP you use '?-'. One feature I like in David Gillespie's enhanced EMACS's info mode (it is not in the standard info mode) that is missing in GAP is the function ','. With 'i' you first specify an pattern. Then ',' lets you visit in turn all nodes that have index entries that match this pattern. One feature I dislike in EMACS' info mode is that I still find it difficult to decipher the information at the top of each node which should tell me where I am. I find GAP's top line much easier to read. David Sibley replied in his e-mail message of 1993/03/11 Eh? I find the GAP online documentation to be excellent. It's much faster and more efficient than anything I ever experienced with EMACS info files, where you have to know where an item is in the heirarchy. "excellent": why, thank you. "faster": I don't think so. In EMACS a special file (info-file) is generated from the TeX manual. This file contains information that allows EMACS' info mode to go very fast from node to node. In GAP the online help always works from the original LaTeX files. To find a node it has to search the 'manual.toc' file, open the chapter file, search linearly to the section, etc. It seems to be fast enough though. Lee Schumacher replied in his e-mail message of 1993/03/11 The ? and ?? are quite useful, its true, but hardly a substitute for a real structured info tree. The problem with the GAP facilities is that you need to know the NAME of the function or concept before you can find it. Of course the topic of discourse in GAP is sufficiently narrow that this is not a problem in general. However I did read the manual off line first and now ? is useful more as a memory jogger. Note that emacs info files are intended more for learing new concepts and groups of commands or functions. If you just want to find a command and you have a pretty good idea what the name is then you use apropos, which provides all of the functionality of ? and ??. I argue that the GAP manual is tree structured (into chapters and sections), and that the online help allows you to search through this structure. In the online help the top node is '?chapters', with references to the first sections of all chapters. And the first section of each chapter contains references (of the form (see "
")) of all the sections of this chapter. So the tree is quite shallow (of depth 2, except in "Group", where it has depth 3), but it's a tree nevertheless. The chapter that you get with '?About GAP' is certainly not a reference manual. It's main purpose is to learn about the (new) concepts in GAP. I know that not all sections of this chapter are easily read online, but the first few certainly are. Arnaldo Mandel replied in his email of 1993/03/11 I don't [find GAP's online help more convenient than EMACS' info]. But the whole discussion is boiling down to a matter of personal preferences. Since I live most of the time within emacs, and maintain it here, it is perhaps natural that I have become addicted to info. On the other hand, I will retract my complaints about lack of "good online documentation" (I had no intention of putting down ? and ??), and qualify it instead as a "lack of an online manual of the kind *I* find convenient". Now, perhaps I would have kept to myself about info, if it wasn't for the circunstance that a hypertext version of GAP documentation had been created, for another plataform. The source code for GAP shows that emacs was a heavily used tool for development; maybe the developers of GAP would have something to say on this matter. I havn't ever used OS/2's IPF. Also Hypertext is such a buzzword. Could somebody enligthen me about IPF's features? I use EMACS a lot. Actually I probably would be lost without EMACS.I don't think it would be too difficult to make a TeXinfo manual for GAP, but we are certainly not considering it in the moment. (I don't miss a GAP info-file for EMACS, but then I probably have to use the manual less often than others ;-). Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From hwb@machnix.mathematik.uni-stuttgart.de Fri Mar 12 23:58:06 1993 From: hwb@machnix.mathematik.uni-stuttgart.de "Harald Boegeholz" Date: Fri, 12 Mar 93 23:58:06 +0100 Subject: RE: new GAP for OS/2 with hypertext documentation Date: Fri, 12 Mar 93 17:22:23 +0100 From: martin@bert.math.rwth-aachen.de ( Martin Schoenert) I havn't ever used OS/2's IPF. Also Hypertext is such a buzzword. Could somebody enligthen me about IPF's features? I can, of course :-). An IPF document is created from an ASCII file that contains certain tags. This is done using a compiler, IPFC. The compiler is part of the OS/2 2.0 Developer's Toolkit, i.e., not generally available for free. The resulting .INF file can be read with OS/2's builtin VIEW command. The finished document has the following features: It is displayed in a window with scrollbars and buttons, i.e., can be operated conveniently with a mouse. The document is hierarchically structured (in the case of the GAP manual in two levels), and there is a contents window that shows you this tree. Inside a section, text can be displayed in several fonts (I used that for the GAP docs), and graphics. A section can contain hypertext links, i.e., words or phrases that are displayed in a different colour. Clicking on them with the mouse takes you directly to the referenced section. The references "..." in the GAP manual were of course idial candidates for conversion to such links. An index window is available too. This window contains an alphabetical index made up from user specified keywords. For the GAP manual, I used the \index entries contained in the \TeX manual. Again, clicking on an index entry directly takes you to the referenced section. A search function lets you search for any phrase either in the index or in the full text of all secions. You get a list of all search hits and can pick the desired secion(s) from that list. IPF has quite a few more features, but I don't want to bore you too much. I must point out that my INF version of the GAP documentation still has quite a few unconverted \TeX commands in it. In particular, I made no attempt at converting the math formulas, so they look as ugly as they do in the regular GAP online documentation. Hope this was of general interest. Harald P.S.: I will be on vacation for three weeks starting tomorrow, and won't be able to participate in this discussion during this time. -- Harald Boegeholz |Home: hwb@texnix.stgt.sub.org (read daily) |University: hwb@machnix.mathematik.uni-stuttgart.de |please don't send large (>100k) mail to my home address. From sibley@math.psu.edu Sun Mar 14 00:49:30 1993 From: sibley@math.psu.edu "David Sibley" Date: Sun, 14 Mar 93 00:49:30 +0100 Subject: character tables I finally got version 3.2. Playing with the new features, I tried gap> g:=ThreeGroup(243,1);; gap> t:=CharTablePGroup(g);; It took just about an hour to construct the character table. This is a lot more than I am used to for groups of this size (roughly) from version 3.1. However, I was appalled when I looked more closely and discovered this group is the cyclic group of order 243. An hour to find the character table of a cyclic group? (This is actual running time, according to ps.) Is there some flaw in the method being used here? I am a bit worried that there might be similar performance problems if a group happens to have a large cyclic subgroup or quotient group in the wrong place. Note this is on a clunky old Sparcstation 1+, no speed demon, using the binary I got from wuarchive.wustl.edu. I haven't compiled GAP 3.2 locally yet, but I intend to. Character tables of other groups of order 243 seem to be constructed much faster (minute or two). So far the cyclic one is the only one like this I have found. David Sibley NT3O sibley@math.psu.edu From SPIT@vm.ci.uv.es Mon Mar 15 11:37:11 1993 From: SPIT@vm.ci.uv.es "Werenfried Spit" Date: Mon, 15 Mar 93 11:37:11 +0100 Subject: GAP for the Macintosh: for the impatient Hello, For those who want to run gap on their macintosh but cannot wait until it is ported there, there is an alternative. Recently a port of MiNT for the macintosh was released. This is an implementation of an alternative OS for the atari to run on the mac; it enables the user to run atari programmes on a macintosh (as long as these programmes don't use the atari specific graphics (GEM) libraries). It can run the atari executable of gap. You can get MacMiNT by gopher from june.jpl.nasa.gov. Two more notes: * You need to set the memory allocation of MiNT from 1300kByte to something higher than 2Mbyte to be able to run gap.ttp * MacMiNT is still only an alpha release, so it might be shaky (says its author). I haven't had any problems upto now running gap, form reduce and a C compiler. A hint to gap-developers: a quick way to get a standalone version of gap for the mac might be the approach of MacForm: this algebraic manipulation programme was ported to the mac by making a little macintosh programme that calls the atari ST executable of Form. In this way updates are easily made since the mac front end need not be changed, and the compilation of form is simple on the ST, just as in the case of gap (as explained in chapter 47 of the gap manual). --------------------------------------------------------------------- Werenfried Spit Departament de Fisica Teorica tel: +34-6-386 4550 Universitat de Valencia ---changedY c/ dr. Moliner, 50 e-mail: spit@vm.ci.uv.es 46100 Burjassot, Valencia spit@ific.uv.es Espanya spit@evalun11.bitnet --------------------------------------------------------------------- From ahulpke@bert.math.rwth-aachen.de Mon Mar 15 14:49:21 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Mon, 15 Mar 93 14:49:21 +0100 Subject: Re: character tables Dear GAP-Forum, in his letter, David sibley wrote: > gap> g:=ThreeGroup(243,1);; > gap> t:=CharTablePGroup(g);; > > It took just about an hour to construct the character table. This is a > lot more than I am used to for groups of this size (roughly) from > version 3.1. However, I was appalled when I looked more closely and > discovered this group is the cyclic group of order 243. An hour to find > the character table of a cyclic group? (This is actual running time, > according to ps.) Naturally, it is disappointing, if an algorithm shows poor performance in trivial cases. However, this special example will also run as fast (or better: as slow) in GAP-3.1. To explain this seemingly strange behaviour, one has to look a bit inside the algorithms: Computing character tables can be a very tedious task. Especially, there are some time consuming subroutines, that have to be called very often (like identification of a class). Thus, the routines do some pre-computation to make things faster afterwards. However, if you are dealing with an abelian or even a cyclic group, these computations, do not need to be done, as one can write down the appropriate character table from scratch. The only real 'task' to be done is attaching the classes of the group to the appropriate column of the character table. Thus the question would be: Why doesn't the routine detect, that computation will be that simple? CharTablePGroup is a routine, that computes the character table, using the algorithm of U. Baum as explained by Thomas Breuer in some previous mail to the forum. In the next version (hopefully, this was left out of 3.2 due to time reasons and since the computation of character tables of cyclic groups was not very high on our schedule), the general dispatcher CharTable will provide an all-purpose routine for computing character tables. This implies, that computations will be shortened for abelian groups. A routine like CharTablePGroup still will exist, and provide the specific algorithm, which might result in poor performance for specific examples. > Is there some flaw in the method being used here? I would not call this behaviour a 'flaw'. CharTablePGroup is a specific routine. Adding examinations of special cases to this routine will result in poorer performance in all other cases, since the test for this special case must be run always. The handling of these special cases is a task of the more general dispatcher. The user may then choose, if he uses the general, or a specific routine: The general routine is slower, but takes the task of selecting a specific routine itself (though this selection might be not as perfect, as the one done by a human). It is just a question, how thinking is divided between human and computer. > I am a bit worried > that there might be similar performance problems if a group happens to > have a large cyclic subgroup or quotient group in the wrong place. This behaviour most likely will reappear, if the group has a large cyclic factorgroup. To cope with this beaviour surely is part of the DWIM (Do What I Mean) problem (baptized this way by Charles Leedham-Green): If I ask the computer to compute the character table of a large abelian group, most likely, I'm not interested in a long list of irreducible characters (unless I want to check memory allocation routines...). The information, I can make use of, would be, that the group *is* abelian, that the structure is Z_a x Z_b x ..., and maybe in *some* irreducible characters, from which the other ones can be obtained by tensor products. If I have a group with a large cyclic factorgroup, either the group itself is very large --- then the cyclic factor will not count --- or the cyclic factor is of disproportional size, compared to the normal subgroup. Then the group most likely is of some special structure, and much more information can be gained, if I use this special structure. Of course this implies, that special algorithms for special structures should be available, i.e. the program should behave 'intelligent'. Reaching that point will mean *a lot* of work, I do not even dare to estimate. Finally, I still did not answer, how to cope with this behaviour (unless one wants to wait centuries for the finished GAP 3.$\infty$). I can only give some suggestions for coping with it: Before computing a character table, I would check, how many conjugacy classes the group has. In the problematic cases, the group will have a lot of classes. Afterwards one can decide, if one *really* wants the character table of that kind of group. (In case if one wants it, there still is the question, whether the table should be computed from the group --- which is only necessary, if one wants a correspondence of class representatives and columns --- or whether one will compute the table itself by CharTableDirectProduct or similar.) In case, this does not help for your particular problem, feel free to ask; maybe there is a problem, we never thought about. I hope this rather lengthy pamphlet has shed some light on this problem. Alexander Hulpke From sibley@math.psu.edu Mon Mar 15 22:23:15 1993 From: sibley@math.psu.edu "David Sibley" Date: Mon, 15 Mar 93 22:23:15 +0100 Subject: bug in TransformingPermutations? This is with 3.2 running on a Sun Sparcstation 1+ with the distributed binary obtained from wuarchive.wustl.edu. Looks like it is asking for the length of a non-existant list. Other than that, I have no idea what the trouble is. I'd appreciate a workaround. gap> g:=ThreeGroup(243,4);; gap> h:=ThreeGroup(243,5);; gap> gt:=CharTablePGroup(g);; gap> ht:=CharTablePGroup(h);; gap> x:=TransformingPermutationsCharTables(gt,ht); Error, List Element: [6] must have a value at return Length( fam1.permutations[x] ) <> Length( fam1.permutations[bij_rows[x]] ) ... in func( l ) called from ForAny( [ 1 .. Length( bij_rows ) ], function ( x ) ... end ) called from TransformingPermutations( tbl1.irreducibles, tbl2.irreducibles ) called from TransformingPermutationsCharTables( gt, ht ) called from main loop brk> From sibley@math.psu.edu Mon Mar 15 23:07:50 1993 From: sibley@math.psu.edu "David Sibley" Date: Mon, 15 Mar 93 23:07:50 +0100 Subject: Re: Bug in TransformingPermutations? It looks like the problem may actually be with ForAny. From what I can see in the documentation, the following should work (returning false) but does not. It's not clear that this is the same bug. The error message is different. gap> a:=[1,2]; [ 1, 2 ] gap> ForAny([a,a,,,a,a],x->Length[x]>2); Error, List Element: must be a positive integer at return Length[x] > 2 ... in func( l ) called from ForAny( [ a, a,,, a, a ], function ( x ) ... end ) called from main loop brk> From sibley@math.psu.edu Mon Mar 15 23:22:33 1993 From: sibley@math.psu.edu "David Sibley" Date: Mon, 15 Mar 93 23:22:33 +0100 Subject: Re: Bug in TransformingPermutations? Arrgh. Ignore that about ForAny. Soon I hope to learn the difference between parentheses and square brackets. From martin@bert.math.rwth-aachen.de Mon Mar 15 23:53:23 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Mon, 15 Mar 93 23:53:23 +0100 Subject: Re: bug in TransformingPermutations? David Sibley writes in his e-mail message of 1993/03/15 This is with 3.2 running on a Sun Sparcstation 1+ with the distributed binary obtained from wuarchive.wustl.edu. Looks like it is asking for the length of a non-existant list. Other than that, I have no idea what the trouble is. I'd appreciate a workaround. gap> g:=ThreeGroup(243,4);; gap> h:=ThreeGroup(243,5);; gap> gt:=CharTablePGroup(g);; gap> ht:=CharTablePGroup(h);; gap> x:=TransformingPermutationsCharTables(gt,ht); Error, List Element: [6] must have a value at return Length( fam1.permutations[x] ) <> Length( fam1.permutations[bij_rows[x]] ) ... in func( l ) called from ForAny( [ 1 .. Length( bij_rows ) ], function ( x ) ... end ) called from TransformingPermutations( tbl1.irreducibles, tbl2.irreducibles ) called from TransformingPermutationsCharTables( gt, ht ) called from This function was written by Tomas Breuer and I don't pretend to fully understand it, so take my comments with a grain of salt. It seems that this problem can only happen if there is no transforming permutation. I hope this is enough of a workaround. More background. 'TransformingPermutations' first groups the characters of each table in families. Two characters are in a family if they are equal when sorted (e.g., '[1,-1,1,-1]' is in the same family as '[1,1,-1,-1]', but not in the same family as '[1,-1,-1,-1]'). A necessary condition for the existence of a transforming permutation is a bijection between the list of families, i.e., every family of 'gt' must also be a family of 'ht' (this is tested twice), and every family of 'ht' must also be a family of 'gt' (this is *not* tested). The test that fails is the test that the corresponding families of 'gt' and 'ht' also have the same number of characters in them. David writes in another e-mail message of 1993/03/15 It looks like the problem may actually be with ForAny. From what I can see in the documentation, the following should work (returning false) but does not. It's not clear that this is the same bug. The error message is different. gap> a:=[1,2]; [ 1, 2 ] gap> ForAny([a,a,,,a,a],x->Length[x]>2); Error, List Element: must be a positive integer at And in yet another e-mail message Arrgh. Ignore that about ForAny. Soon I hope to learn the difference between parentheses and square brackets. Have you been using Mathematica lately? ;-) Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From am@ime.usp.br Tue Mar 16 00:10:55 1993 From: am@ime.usp.br "Arnaldo Mandel" Date: Tue, 16 Mar 93 00:10:55 +0100 Subject: Re: RE: new GAP for OS/2 with hypertext documentation Martin Schoenert writes: [an interesting comparison of emacs info and GAP'S on-line help] First of all, this comparison and your later comments on how much you use emacs are bound be an enticement for those GAPers (?) who are not emacs users to try it out :-) Let me see what I think I miss from info on GAP. First of all, the familiar interface. I have learned already an uncountable number (even though it is finite) of user interfaces on several classes of similar programs; it is not so difficult to keep them straight as long as they are used frequently, but it sure is boring. Anyway, GAP's keycodes aren't even close to the torture of using vi *occasionaly*, something I have to cope with, so let it be. On this site, the X interface of GNU Emacs is all souped up with goodies I have come to get used. Thus, for some stuff, like following chapters, references and other hypertext links, the mouse comes in handy. And one can add hyperbole buttons in such a way that an info file can have attached postscript or dvi files, which would be shown in the screen adequately. And then, I can easily pluck pieces of an info file into a buffer (but this is cheating, since I already said I use a mouse, I can pick up stuff from an xterm too). > I use EMACS a lot. Actually I probably would be lost without EMACS.I > don't think it would be too difficult to make a TeXinfo manual for GAP, I am flabbergasted! I thought it would be a HUGE amount of work, given the size of the GAP manual. Actually, that was the main reason I never asked for it, until I was prompted by the posting about hypertext. > but we are certainly not considering it in the moment. (I don't miss a Joachim's last posting surely set the priorities straight. The lack of an info is at most a very minor deficiency of GAP; surely the team energies are better spent into improving GAP's mathematical abilities and computational power. > GAP info-file for EMACS, but then I probably have to use the manual less > often than others ;-). Saved yourself a backache from carrying a 2 kg GAP manual up and down :-) Best regards, Arnaldo ................................................................. Arnaldo Mandel \ am@ime.usp.br (1st choice) Computer Science Dep. \ amandel@cce.usp.br (2nd) Universidade de S\~{a}o Paulo / mac@fpspux.fapesp.br S\~{a}o Paulo - SP - Brazil / (if all else fails) From ahulpke@bert.math.rwth-aachen.de Tue Mar 16 18:26:03 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Tue, 16 Mar 93 18:26:03 +0100 Subject: CharTablePGroup and abelian groups He tried the instruments as no one else had tried them; he destroyed them, one after another, as fast as they could be made and sent him, till the patience of Mr. Sholes [the inventor] was exhausted. But Mr. Densmore insisted, that this was the very salvation of the enterprise; that it showed the weak spots and defects, and that the machine must be made so that anybody could use it, or all efforts might as well be abandoned; that such a test was a blessing and not a misfortune, for which the enterprise should be thankful. Donald A. Norman, The design of everyday things Dear GAP-Forum, A few days ago, David Sibley noted a somehow strange behaviour in CharTablePGroup, whenever occuring an abelian group. I tried to answer this letter in pointing out, that computing a character table of an abelian group perhaps is not an too good idea. However, further analysis led to the conclusion, that this effect could not be resposible for a behaviour *that* bad. An examination of the execution of the algorithm showed, that there was indeed an flaw, which was responsible not only for the poor performance on the cyclic group, but also for a decerease of speed in the general case. As a result, the thus modified algorithm runs about a factor 2-15 (15 for abelian groups) faster, than the former version, resulting in an improvement in speed about at least the factor 3-4 in the 'mean' case. (These factors are based on computing the character tables of all groups of order 243). I'd like to thank David Sibley for pointing us to this case. We depend on the aid of users for finding errors like these, that may remain undetected when running examples. Alexander Hulpke From jcbhrb@cerf.net Wed Mar 17 05:52:18 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Wed, 17 Mar 93 05:52:18 +0100 Subject: Infinite matrix groups gap-forum@samson.math.rwth-aachen.de The section "About Matrix Groups" in the manual says : " ... Especially inifinite matrix groups (over the rationals or cyclotomic fields) can not be dealt with at all. " Now what I am trying to do is not very complicated : starting with a small number of rational matrices which I know generate an infinite group, I'd like to get the first 1000 or so elements (as generated by any algorithm for now; later I would like add some selection rules). Is this also impossible? if it is then which of the "internal" programs should I look at to get an idea of what's involved?. Thanks. Jacob Hirbawi JcbHrb@CERF.net PS. This has to do with a number of problems in crystallography that I'd like to look at using GAP. If anyone else has done any work along these lines or has any suggestions please let me know. Thanks. From neubuese@samson.math.rwth-aachen.de Wed Mar 17 09:35:46 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Wed, 17 Mar 93 09:35:46 +0100 Subject: Re: Infinite matrix groups Jacob Hirbawi asked about the possibility to calculate with the elements of an infinite matrix group over the rationals. That is indeed possible as well as the calculation with matrices over cyclotomic fields, it is just that most of the general group functions cannot be used. Frank Celler is answering that in more detail. However,in a PS you say that this has to do with a number of problems in crystallography and since in the past I have been working on crystallographic groups making heavy use of computer methods (e.g. for the classification of the four-dimensional point and space groups), I am curious to know what you are after. possibly we or others might even have some suggestions how to use GAP for the problems. Joachim Neubueser From fceller@bert.math.rwth-aachen.de Wed Mar 17 10:02:15 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Wed, 17 Mar 93 10:02:15 +0100 Subject: Re: Infinite matrix groups Dear Gap Forum, Jacob Hirbawi asked about a way to construct the first 1000 elements of an infinite matrix group. It is true, that the 'Random' function will not work for infinite matrix groups, because 'Random' (and many other matrix group functions) try to construct an isomorphic permutation group. However, if you have a matrix of finite order you can asked for its order. But if your matrix has a very large orbit, this function will run for ages, because it constructs orbits in order to find the order of the matrix. In order to construct elements of an infinite matrix group, one could form random products in the generators. I have found to following heuristic useful for matrix groups over finite fields: Create a product of 100 * Length(G.generators) randomly chosen generators as seed, and multiply this seed from the left or right (again randomly chosen) with a random generator for the next element. This random function is used in a program which will try to decide whether a given group over a finite field contains the SL or not. If your group is called G the following program will generate 1000 Elements of G: E := []; while Length(E) < 1000 do AddSet( E, RecSL.Random(G,0) ); od; As this function 'RecSL.Random' does not invert the generators, you might want to add the inverses of the generators of your matrix group to the generators of G. As you are (maybe) not interested in (pseudo) random elements, you should skip the seed generating process by starting with the identity as seed element: G := Group( m1, ..., mn ); G.randomSeed := G.identity; best wishes Frank Celler From dfh@maths.warwick.ac.uk Wed Mar 17 10:42:34 1993 From: dfh@maths.warwick.ac.uk "Derek Holt" Date: Wed, 17 Mar 93 10:42:34 +0100 Subject: Re: Infinite matrix groups The problem as stated was to get the `first' 1000 or so elements of an infinite matrix group rather than a random collection of elements. Suppose the matrix group G is generated by g_1,...,g_n. It seems to me that the natural way to do this is to start with the free group F on generators x_1,...,x_n, and define the obvious epimorphism phi from F to G. Now generate the first 1000 or so elements of F, using the usual length-lexicographic ordering, and take the images of these words under phi. There are two problems. Firstly, there does not currently appear to be a GAP function to spew out elements in a free group in order, although there probably should be, and it would not be too hard to write. Secondly, if the matrix group G has nontrivial relations, then the list of elements in G produced will have some repetitions. If only about 1000 elements are needed, then it would not be difficult to look for these repetitions directly (perhaps using hash tables). Better still, if one knows defining relations for G, then the Knuth-Bendix procedure can be used to generate all relations in G systematically, and then it is possible to produce repetition-free lists directly. Of course, this is not yet possible in the GAP system, but the relevant software does exist. We have used this technique to good advantage at Warwick in connection with automatic groups. It has led to spectacular improvements in efficiency in programs which draw pictures for analysts and topologists, etc. Derek Holt. From neil@dehn.mth.pdx.edu Wed Mar 17 18:21:33 1993 From: neil@dehn.mth.pdx.edu "John R. Neil" Date: Wed, 17 Mar 93 18:21:33 +0100 Subject: Group rings of AG-Groups I have need to do calculations with group rings of ag-groups. Does GAP know how to deal with this already or am I looking at defining a new domain? If someone has already done something with this, I would appreciate knowing what it is. --John Neil =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Neil e-mail: neil@math.mth.pdx.edu Director of Computer Labs and UNIX System Administrator Portland State University Mathematics Department =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From ahulpke@bert.math.rwth-aachen.de Wed Mar 17 18:43:15 1993 From: ahulpke@bert.math.rwth-aachen.de "Alexander Hulpke" Date: Wed, 17 Mar 93 18:43:15 +0100 Subject: Re: Group rings of AG-Groups In his message, John Neil asked: > > I have need to do calculations with group rings of ag-groups. Does GAP know > how to deal with this already or am I looking at defining a new domain? If > someone has already done something with this, I would appreciate knowing what > it is. > Group Rings are not a built-in object. If the groups, in which you want to compute are not too big (basically this means, that you can keep a list of all group elements in memory at the same time and you are prepared to wait for multiplications --- multiplication is done by simple distributive expansion of sums, thus requires a lot of products to be computed), I can provide some basic routines, I wrote some time ago. They provide a group algebra as an vector space of dimension $|G|$, the basis corresponding to the group elements. Thus elements are represented as sums of group elements. Supported operations are almost only the basic ring operations +, -, *. Alexander Hulpke From geck@dmi.ens.fr Thu Mar 18 08:34:08 1993 From: geck@dmi.ens.fr "Meinolf Geck" Date: Thu, 18 Mar 93 08:34:08 +0100 Subject: J.Neils question about computations in group rings Dear Prof. Neil, in GAP-3.2 there is a package containing programs for working with Weyl groups and associated Hecke algebras. The latter are certain deformations of the group ring of the first. There are programs to do computations in this algebra, e.g. multiplying two basis elements and expressing the result as a linear combination of the basis vectors. (I am not certain whether or not GAP has already some built-in functions for comptations in group rings). Maybe looking at the code or the documented examples in the chapter 'Weyl group and Hecke algebras' of the manual might help you? Sincerely yours, Meinolf Geck (Lehrstuhl D f"ur Mathematik, RWTH Aachen) From neubuese@samson.math.rwth-aachen.de Thu Mar 18 10:05:34 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 18 Mar 93 10:05:34 +0100 Subject: Re: Group rings of AG-Groups There have been already two attempts to answer J. Neil's question about possibilities of calculating in group rings of AG groups. Let me give a third hint: Martin Wursthorn at Stuttgart (working in the group of Prof. Klaus Roggenkamp) has a set of standalone programs written for the investigation of modular group rings of *p-groups* (given by a polycyclic presentation) which e.g. computes automorphism groups of p-groups but also unit groups of such group rings. Together with Martin Wursthorn we are planning to make this set of programs available as a further "share library" through GAP in the not too far future. Maybe this is of interest. Joachim Neubueser From kaup@ccucvx.unican.es Thu Mar 18 18:13:29 1993 From: kaup@ccucvx.unican.es "Ansgar Kaup" Date: Thu, 18 Mar 93 18:13:29 +0100 Subject: ? Bug in ElementProperty ? I gave the following GAP-Commands : gap> a:=(1,2)(3,5)(4,6)(7,10);; gap> b:=(2,3,4)(5,7,8)(6,9,10);; gap> G:=Group(a,b);; gap> PermGroupOps.ElementProperty(G,g->a^g=a); () gap> C:=Centralizer(G,a); Subgroup( Group( ( 1, 2)( 3, 5)( 4, 6)( 7,10), ( 2, 3, 4)( 5, 7, 8) ( 6, 9,10) ), [ ( 3, 4)( 5, 6)( 7,10)( 8, 9), ( 1, 2)( 3, 5)( 4, 6)( 7,10) ] ) gap> c1:=C.generators[1];; gap> c2:=C.generators[2];; gap> a^c1; ( 1, 2)( 3, 5)( 4, 6)( 7,10) gap> a^c2; ( 1, 2)( 3, 5)( 4, 6)( 7,10) I think that the command PermGroupOps.ElementProperty should have returned one of the two generators of C or at least a product of them. Is there an Error or do I make anything wrong ? Saludos, Ansgar From martin@bert.math.rwth-aachen.de Thu Mar 18 18:21:25 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Thu, 18 Mar 93 18:21:25 +0100 Subject: Re: ? Bug in ElementProperty ? Ansgar Kaup asks in his e-mail message of 1993/03/18: I gave the following GAP-Commands : gap> a:=(1,2)(3,5)(4,6)(7,10);; gap> b:=(2,3,4)(5,7,8)(6,9,10);; gap> G:=Group(a,b);; gap> PermGroupOps.ElementProperty(G,g->a^g=a); () I think that the command PermGroupOps.ElementProperty should have returned one of the two generators of C [the centralizer of a] or at least a product of them. Is there an Error or do I make anything wrong ? You get what you ask for. You want an element that centralizes 'a', you get one. Not only that. In fact you even get the *smallest* such element (but this is not guaranteed). Maybe you want to rewrite your test as 'g->a^g=a and g <> ()'?. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From jcbhrb@cerf.net Fri Mar 19 08:46:16 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Fri, 19 Mar 93 08:46:16 +0100 Subject: Infinite matrix groups gap-forum@samson.math.rwth-aachen.de Thanks to Joachim Neubueser, Frank Celler, and Derek Holt for their responses regarding my question on infinite matrix groups. I'd like to make these comments in return: (1) I think the first method suggested by Derek Holt is very close to what I had in mind for getting the 'first' 1000 elements of an infinite group; I will try generating more and more elements of the free group while watching for repetitions (until I get 1000). As noted there doesn't seem a GAP function that does that, but I agree that it should be easy to implement one; an advantage of this is that I know how to add 'selection rules' for which elements to accept. I was hoping to find something more sophisticated and it seems that such an algorithm exists. Two catches though! : it is not part of GAP (yet), and it assumes that you know the defining relations of the group (for this particular problem, I don't, I only have matrices). This algorithm would be a nice addition to GAP someday; in the mean time I would be interseted to know more about the existing software and I think that others might be too. I'll leave it to Derek's discretion to tell more about his software by e-mail or through the forum -- when he's not too busy of course :-) (2) Frank Celler's heuristic method would probably involve the least amount of work on my part and so I will try it first. I suspect that this would not really give me the elements that I am looking for but hopefully I'm wrong! (3) I am glad to get a response from Dr. Neubueser on this since I am well aware of his work (with others) on the classification of the the four dimensional space groups; this also makes it easier for me to describe my "wish-list" as far as crytallographic groups are concerned: the short (and and I hope not too blunt :-) ) answer is : all the tables in the book 'Crystallographic Groups in Four Dimensional Space'; It would be so nice to have the generators for all the point groups as well as the full space groups in dimensions 1 to 4 complemented by routines to give such standard data as equivalent positions (for different cernterings) of these groups -- that would make a good part of the International Tables available at your fingertips. I realize that the classification was carried out a number of yeares before GAP was introduced; I am curious to know how much of it can be recreated within GAP today. Once again, thanks to all for their help. Jacob Hirbawi JcbHrb@CERF.net From leh@aberystwyth.ac.uk Fri Mar 19 10:49:11 1993 From: leh@aberystwyth.ac.uk "Lee Hawkins" Date: Fri, 19 Mar 93 10:49:11 +0100 Subject: Linear combinations in Gap To The Gap Forum, Hope this question is not too trivial for the forum, but I'm not very experienced with Gap. My problem is the following : I have a list of lists, each of which I wish to express as a Z-linear combination of a set of given lists (each list involved consists of integers). How can I do this in Gap 3.2 ????? Any help appreciated, thanx in advance, Lee Hawkins (Dept. of Pure Mathematics, University of Wales, Aberystwyth, UK) From sam@ernie.math.rwth-aachen.de Fri Mar 19 12:45:34 1993 From: sam@ernie.math.rwth-aachen.de "Thomas Breuer" Date: Fri, 19 Mar 93 12:45:34 +0100 Subject: Re: Linear combinations in Gap Dear Mrs. and Mr. Forum, Lee Hawkins writes in his mail > I have a list of lists, each of which I wish to express as a Z-linear > combination of a set of given lists (each list involved consists of > integers). How can I do this in Gap 3.2 ????? Let 'X' be an integral matrix with linearly independent rows, and 'b' an integral vector of same dimension as the rows of 'X'. The GAP function 'Decomposition' computes the integral coefficient vector 'a' (if exists) such that 'a * X = b'. The method used is p-adic approximation, that is, a square submatrix of 'X' of full rank is inverted modulo a suitable prime p, and the initial part of the p-adic series of a solution 'a' is computed. If no solution is found then 'false' is returned, what means that either no integral solution exists or the maximal length of the computed initial part was chosen too small. The details can be found in the GAP manual in section "Decomposition". It should be noted that 'X' need not be integral, the algorithm also works for matrices over the ring of cyclotomic integers. Best wishes, Thomas Breuer (sam@ernie.math.rwth-aachen.de) From digne@dmi.ens.fr Mon Mar 22 14:20:52 1993 From: digne@dmi.ens.fr "Francois Digne" Date: Mon, 22 Mar 93 14:20:52 +0100 Subject: Leonard Soicher's Package for computing graphs automorphisms Dear Gap-forum I have been told that Leonard Soicher has written a GAP package for computing automorphism groups of graphs. Where could I get it? Francois Digne From sl25@cus.cam.ac.uk Mon Mar 22 14:48:30 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Mon, 22 Mar 93 14:48:30 +0100 Subject: Re: Leonard Soicher's Package for computing graphs automorphisms It's available for anonymous FTP from galois.maths.qmw.ac.uk in directory /pub. The filenames are grape.README and grape.tar.Z. The actual automorphism group calculations are performed by calling Brendan McKay's nauty program. Steve Linton From sl25@cus.cam.ac.uk Tue Mar 23 17:04:13 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Tue, 23 Mar 93 17:04:13 +0100 Subject: Inconsistencies in new string, list and range features. 1) While strings are lists, string literals do not appear to be usable as such: gap> "abc"[1]; Syntax error: ; expected "abc"[1]; ^ gap> ("abc")[1]; Syntax error: ; expected ("abc")[1]; ^ gap> l := "abc"; "abc" gap> l[1]; 'a' Actually the second example above seems to be an instance of something more general: gap> (l)[1]; Syntax error: ; expected (l)[1]; ^ 2) I think the following should work: gap> [y := 9, y-1 ..1]; Syntax error: ] expected [y := 9, y-1..1]; ^ This may look stupid, but suppose 9 were replaced by an expensive function call. gap> y := 9; [y,y-1..1]; 9 [ 9, 8 .. 1 ] works, but seems unnecessarily long. Actually, the best way to cope with this situation would be to be able to specify the step explicitly in a range literal, something like [start, end : step]. Steve From martin@bert.math.rwth-aachen.de Tue Mar 23 19:25:06 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Tue, 23 Mar 93 19:25:06 +0100 Subject: Re: Inconsistencies in new string, list and range features. Steve Linton writes in his e-mail message of 1993/03/23 1) While strings are lists, string literals do not appear to be usable as such: gap> "abc"[1]; Syntax error: ; expected "abc"[1]; ^ This is not a problem of strings. The same ``problem'' appears with any list. I.e., '[2,3,5,7,11][3]' is also not allowed. The BNF syntax shows you that left of the '[' there must be a *variable*, i.e., either '', '.', or '.[]'. It would be possible to change the parser to allow something like '[]', but frankly this doesn't seem very important. Steve Linton continues: 2) I think the following should work: gap> [y := 9, y-1 ..1]; Syntax error: ] expected [y := 9, y-1..1]; ^ This may look stupid, but suppose 9 were replaced by an expensive function call. gap> y := 9; [y,y-1..1]; 9 [ 9, 8 .. 1 ] works, but seems unnecessarily long. Actually, the best way to cope with this situation would be to be able to specify the step explicitly in a range literal, something like [start, end : step]. Since ranges are internally stored as triple , , , a syntax of the form '[ .. by ]' would not pose any difficulties. Maybe some day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From rbiggers@kscsuna1.kennesaw.edu Wed Mar 24 16:49:33 1993 From: rbiggers@kscsuna1.kennesaw.edu "Ronald Biggers" Date: Wed, 24 Mar 93 16:49:33 +0100 Subject: Permutation Representations of Wreath Products Dear Gap Forum, I am presently using the DOS version of GAP 3.1. What must I do to correct the following error(s)? gap> z2 := Group( (1,2) );; gap> z2.name := "z2";; gap> g4 := Group( (1,3)(2,4), (1,2)(3,4) );; gap> g4.name := "g4";; gap> i4 := IdentityMapping( g4 );; gap> g8 := WreathProduct(z2, g4, i4);; gap> gt1 := Subgroup( g8, [ > WreathProductElement( (1,2), (), (), (), (), () ), > WreathProductElement( (), (1,2), (), (), (), () ), > WreathProductElement( (), (), (1,2), (), (), () ) ] );; gap> gt1.name := "gt1";; gap> x1 := Set( RightCosets( g8, gt1 ) );; gap> Operation( g8, x1, OnRightCosets ); Error, for: 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( g8, x1, OnRightCosets ) called from main loop brk> . . . gap> Permutation( WreathProductElement( (1,2), (), (), (), (1,3)(2,4), > (1,3)(2,4) ), x1, OnRightCosets ); Error, for: must evaluate to a list at for in set ... in opr( D[i], g ) called from D.operation.Permutation( arg[1], arg[2], arg[3] ) called from Permutation( WreathProductElement( (1,2), (), (), (), (1,3)(2,3), (1,3)(2, 4) ), x1, OnRightCosets ) called from main loop brk> Ron Biggers Ronald C. Biggers Associate Professor of Mathematics Kennesaw State College P.O. Box 444 Marietta, GA 30061 (404)423-6505 or 6327 Fax (404) 423-6629 From kaskel@math.berkeley.edu Wed Mar 24 23:22:47 1993 From: kaskel@math.berkeley.edu "Bruce Kaskel" Date: Wed, 24 Mar 93 23:22:47 +0100 Subject: problems running GAP on a PC I've recently been trying to install GAP on my PC (486). I've set up the gapexe.386 executable and the \lib and \grp libraries. Hopefully someone out there has been through this and can answer some questions 1) I have not been able to correctly access the grp library. I do not get an error message but the machine simply 'freezes'. For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt and nothing happens. Martin Sch"onert advised me to remove my TSR's and EMM386. I tried this and a variety of other combinations but it's still no good. Can anyone point out what I might be doing wrong? 2) I am currently just trying to get the gapexe.386 port running. However since I am putting it on a 486 I wonder: I assume that gapexe.386 was compiled with 387 emmulation. Is this correct? If so, how much 'speed improvement'/'program size savings' is achieved by compiling for a 387? Thanks in advance for any help offered. Bruce Kaskel kaskel@math.berkeley.edu From sl25@cus.cam.ac.uk Thu Mar 25 11:06:22 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Thu, 25 Mar 93 11:06:22 +0100 Subject: Re: problems running GAP on a PC > > 2) I am currently just trying to get the gapexe.386 port running. > However since I am putting it on a 486 I wonder: > I assume that gapexe.386 was compiled with 387 emmulation. > Is this correct? > If so, how much 'speed improvement'/'program size savings' is achieved > by compiling for a 387? > The DOS extender detects the presence or otherwise of a 387 at run-time and looks for a software emulator only if one is needed. In any event, I don't believe that GAP uses any floating point at all. Steve From L.H.Soicher@qmw.ac.uk Thu Mar 25 11:49:33 1993 From: L.H.Soicher@qmw.ac.uk "Leonard Soicher" Date: Thu, 25 Mar 93 11:49:33 +0100 Subject: Re: problems running GAP on a PC >1) I have not been able to correctly access the grp library. > I do not get an error message but the machine simply 'freezes'. > For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt > and nothing happens. In your batch file to run gap, you should specify the library as -l /lib/ (or whatever). The important thing is to use "/", so that the gap system can modify the string containing the lib directory to determine the grp directory. L.H.Soicher@qmw.ac.uk From martin@bert.math.rwth-aachen.de Thu Mar 25 12:08:58 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Thu, 25 Mar 93 12:08:58 +0100 Subject: Re: Permutation Representations of Wreath Products Ronald Biggers writes in his e-mail message of 1993/03/24 gap> z2 := Group( (1,2) );; gap> z2.name := "z2";; gap> g4 := Group( (1,3)(2,4), (1,2)(3,4) );; gap> g4.name := "g4";; gap> i4 := IdentityMapping( g4 );; gap> g8 := WreathProduct(z2, g4, i4);; gap> gt1 := Subgroup( g8, [ > WreathProductElement( (1,2), (), (), (), (), () ), > WreathProductElement( (), (1,2), (), (), (), () ), > WreathProductElement( (), (), (1,2), (), (), () ) ] );; gap> gt1.name := "gt1";; gap> x1 := Set( RightCosets( g8, gt1 ) );; gap> Operation( g8, x1, OnRightCosets ); Error, for: must evaluate to a list at Once upon a time right cosets weren't domains in GAP. They were simply proper sets (i.e., sorted lists). 'OnRightCosets' then was the function to use for those sets. That is 'OnRightCosets' takes a proper set, multiplies all its elements with , sorts the resulting list, and returns this as the result. Of course representing right cosets as lists was a stupid idea, especially if the subgroup was large (or even infinite). Thus we changed this (between GAP 3.0 and 3.1), so that right cosets are now domains. To find the ``image'' of a right coset under an element you can now write ' * '. Thus you should use 'OnRight' instead of 'OnRightCosets'. gap> Operation( g8, x1, OnRight ); Group( (4,8), (3,7), (2,6), (1,5), (1,3)(2,4)(5,7)(6,8), (1,2)(3,4)(5,6)(7,8) ) Note that GAP 3.2 is a little bit more clever. If both and are permutation groups, then 'WreathProduct( , , )' will automatically be represented as a permutation group. gap> g8 := WreatProduct( z2, g4, i4 ); Group( (1,2), (3,4), (5,6), (7,8), (1,5)(2,6)(3,7)(4,8), (1,3)(2,4)(5,7)(6,8) ) So you don't have to go through 'gt1' and 'x1' to compute a permutation representation any more. On the other hand if you still want to define 'gt1' you now have to specify it as 'Subgroup(g8,[(1,2),(3,4),(5,6)])'. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From martin@bert.math.rwth-aachen.de Thu Mar 25 12:37:35 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Thu, 25 Mar 93 12:37:35 +0100 Subject: Re: problems running GAP on a PC Bruce Kaskell writes in his e-mail of 24-Mar-93 I've recently been trying to install GAP on my PC (486). I've set up the gapexe.386 executable and the \lib and \grp libraries. Hopefully someone out there has been through this and can answer some questions 1) I have not been able to correctly access the grp library. I do not get an error message but the machine simply 'freezes'. For example, I type 'SymmetricGroup(3);' at the 'gap>' prompt and nothing happens. Martin Sch"onert advised me to remove my TSR's and EMM386. I tried this and a variety of other combinations but it's still no good. Can anyone point out what I might be doing wrong? I am sorry, I misunderstood your e-mail. When you wrote that you ``could not use any of the *group functions*'', I interpreted that as ``could not use any of the *library functions*''. You should write the library path in your batch file that starts GAP using slashes '/' instead of backslashes '\'. This is because 'lib/init.g' computes the group path by replacing 'lib/' in 'LIBNAME' by 'grp/'. In any case, start GAP and look at the variables 'LIBNAME' and 'GRPNAME' to see that they make sense. But why would GAP freeze if the 'GRPNAME' is wrong? If I try it here, I just get an error message. Bruce Kaskel continues: 2) I am currently just trying to get the gapexe.386 port running. However since I am putting it on a 486 I wonder: I assume that gapexe.386 was compiled with 387 emmulation. Is this correct? If so, how much 'speed improvement'/'program size savings' is achieved by compiling for a 387? GAP doesn't use any floating point. So there will be no speed improvement. One probably could use a version of 'go32' (the DOS extender) without floating point emulation, but I doubt that the gain in program size is worth the effort. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From mendel@ccu.umanitoba.ca Thu Mar 25 19:06:32 1993 From: mendel@ccu.umanitoba.ca "N. S. Mendelsohn" Date: Thu, 25 Mar 93 19:06:32 +0100 Subject: GAP on the Mac The second version of GAP on the Mac is now available. To obtain it use anonymous ftp to address ccu.umanitoba.ca It is archived at /pub/mac/MacGAP31.sea.hqx Make sure to read the Read Me file. Included is the program and the lib file but not the doc file which you can add on your own. Features are slide bars for scrolling, 'save transcript' and 'save selection'. Also many cut and paste features of the Mac. The porting was carried out by Harry Lakser. If you have any difficulties or find bugs please contact me and copy message to Lakser or writ to Lakser direct. His address is hlakser@ccu.umanitoba.ca N. S. Mendelsohn From mendel@ccu.umanitoba.ca Thu Mar 25 21:07:26 1993 From: mendel@ccu.umanitoba.ca "N. S. Mendelsohn" Date: Thu, 25 Mar 93 21:07:26 +0100 Subject: GAP on Mac In my last letter I forgot to mention that if there is sufficient interest Lakser will port GRAPE to Mac. While the first transfer was an arduous job our experience will make future transfers more or less routine. In particular as soon as GAP 3.2 is implemented on our main-frame it will be ported to the Mac. N. S. Mendelsohn From martin@bert.math.rwth-aachen.de Fri Mar 26 12:57:21 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Fri, 26 Mar 93 12:57:21 +0100 Subject: Upgrade for GAP 3.2 (V3R2) to patchlevel 1 (V3R2P1) This is to announce the availibility of the first upgrade for GAP 3.2. This upgrade brings version 3 release 2 (V3R2) to version 3 release 2 patchlevel 1 (V3R2P1). The priority of this upgrade is medium. The upgrade is available as file 'upg3r2p1.dif.Z' on the 'ftp' server 'samson.math.rwth-aachen.de'. It should be available on the other 'ftp' servers soon. This time I do not send out this upgrade as e-mail, it is simply too large (about 100 KBytes 'compress'-ed). First unpack the upgrade with 'uncompress upg3r1p1.dif.Z'. Then read the beginning of the unpacked file 'upg3r2p1.dif', which contains instructions how to apply this upgrade. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From dana@bimacs.cs.biu.ac.il Tue Mar 31 15:14:39 1993 From: dana@bimacs.cs.biu.ac.il "Dana-Picard Noah" Date: Tue, 30 Mar 93 15:14:39 +0200 Subject: GAP on PC I'm trying to run GAP on a 486 (I got the .exe file); in order to have the new upgrading, I suppose that it's necessary to ftp the .exe again. Is there something else to do? Thanks, Thierry Dana-Picard. From dana@bimacs.cs.biu.ac.il Tue Mar 30 15:24:47 1993 From: dana@bimacs.cs.biu.ac.il "Dana-Picard Noah" Date: Tue, 30 Mar 93 15:24:47 +0200 Subject: Loewy Series I know that the Loewy series of a group can be computed with the help of a certain central series (Jennings's thm). Is there either some feature in GAP which determines this series for a given group or somebody who already wrote a GAP program for that purpose? Thanks in advance for any help, Thierry Dana-Picard. From fceller@bert.math.rwth-aachen.de Tue Mar 30 18:18:32 1993 From: fceller@bert.math.rwth-aachen.de "Frank Celler" Date: Tue, 30 Mar 93 18:18:32 +0200 Subject: Re: GAP on PC Dana-Picard Noah asked I'm trying to run GAP on a 486 (I got the .exe file); in order to have the new upgrading, I suppose that it's necessary to ftp the .exe again. The executables on "samson.math.rwth-aachen.de" are still the old Patchlevel 0 versions. We will try to update the executables as soon as possible, but it will take a few more days. However, if you have GCC 2.3.? installed on your PC, you can apply "upg3r2p1.dif.Z" to the source and recompile the kernel. Is there something else to do? All you need is a running compress, patch program, and "upg3r2p1.dif.Z". Instruction on how to apply the patch are giving at the beginning of this files. best wishes Frank Celler From neubuese@samson.math.rwth-aachen.de Tue Mar 30 18:39:45 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 30 Mar 93 18:39:45 +0200 Subject: Re: Loewy Series Thierry Dana-Picard asked: > I know that the Loewy series of a group can be computed with the help > of a certain central series (Jennings's thm). > Is there either some feature in GAP which determines this series for a > given group or somebody who already wrote a GAP program for that > purpose? There is no function in the present version of GAP to compute the Jennings series of a p-group or the Loewy series of its group ring, while in our old system SOGOS we have a command for the computation of the Jennings series and from it the *dimensions* of the Loewy series. However both are so easily implemented in GAP that Frank Celler will do that right now and send you the functions. Also these functions with full description will probably be put into the next patch. To compute the Loewy series itself is a different matter, this would involve computation in the group ring itself and there are no special provisions for that in GAP at present, so we will not embark on that now. I hope that perhaps the dimensions will do? Joachim Neubueser From webb@s5.math.umn.edu Tue Mar 30 21:04:46 1993 From: webb@s5.math.umn.edu "Peter Webb" Date: Tue, 30 Mar 93 21:04:46 +0200 Subject: Loewy series and representation theory In connection with Thierry Dana-Picard's question about finding Loewy series, I have written several GAP routines which handle group representations which in particular will compute the Loewy series of any representation of a p-group in characteristic p (and more generally the Loewy series of the largest quotient of a module all of whose composition factors are trivial). The algorithm I use is simply to multiply repeatedly by the augmentation ideal. The trouble with this approach if one is interested in the Loewy series of the group ring is that the regular representation has a large dimension, and for reasons of time and storage the problem may become computationally unfeasible that way. Jenning's theorem could be the better approach! On the topic of representation theory within GAP, I have the impression that this side of things has been somewhat neglected so far. The meataxe is implemented, but I have other goals in mind to do with creating software to complement this. For example, the meataxe would not be so good for analyzing the structure of modules for p-groups in characteristic p, but algorithms based upon the computation of fixed points are very effective in this situation. It is a long-term project for me to expand what software I have, and to put it into a publicly acceptable state. Right now, for example, it does not properly conform to the object-oriented style of GAP, and it is not adequately tested. At this point I would be happy to hear of others writing similar software (some I already know of). My general aim is to have a package which computes Loewy series reasonably, will extract a quotient in the Loewy series of a p-group as a representation of its normalizer in a larger group (for example), will compute relative traces between modules of fixed points, and such similar things. Peter Webb webb@math.umn.edu From sibley@math.psu.edu Tue Mar 30 22:15:04 1993 From: sibley@math.psu.edu "David Sibley" Date: Tue, 30 Mar 93 22:15:04 +0200 Subject: error in README I was just browsing the README file distributed with GAP 3.2. In the list of ftp sites, it claims that wuarchive.wustl.edu is the University of Tennessee. However, it is the Washington University of St. Louis: % whois wustl.edu Washington University (WUSTL-DOM) Office of the Network Coordinator One Brookings Drive Campus Box 1048 St. Louis, MO 63130-4899 [much more info, deleted to save space] From martin@bert.math.rwth-aachen.de Wed Mar 31 09:34:25 1993 From: martin@bert.math.rwth-aachen.de "Martin Schoenert" Date: Wed, 31 Mar 93 09:34:25 +0200 Subject: Re: error in README David Sibley wrote in his e-mail message of 1993/03/30 I was just browsing the README file distributed with GAP 3.2. In the list of ftp sites, it claims that wuarchive.wustl.edu is the University of Tennessee. However, it is the Washington University of St. Louis: % whois wustl.edu Washington University (WUSTL-DOM) [...] Mmm, yes. Prof. Larry Husch, one of the moderators of the Mathematics Archives on 'wuarchive.wustl.edu' asked us whether it would be ok to put GAP on 'wuarchive.wustl.edu'. He is from the Univ. of Tennessee. This is the source of our confusion. I corrected this in the 'README' file. Thanks, Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From neubuese@samson.math.rwth-aachen.de Wed Mar 31 10:05:15 1993 From: neubuese@samson.math.rwth-aachen.de "Joachim Neubueser" Date: Wed, 31 Mar 93 10:05:15 +0200 Subject: CGT workshop in Galway On March 10, Ted Hurley posted a brief announcement of the Groups'93 Galway/St.Andrews meeting in this forum in which he mentioned that during the second week we would organize a workshop on Computational Group Theory using GAP. Here is a tentative plan for this workshop. ====================================================================== Workshop Computational Group Theory and the use of GAP during the second week of Groups 1993 Galway/St.Andrews August 9 - 13, 1993. The workshop is intended to introduce group theoreticians to the algorithmic methods presently available for the investigation of finite groups and their (ordinary and modular) representations and of finitely presented groups as well as to practical application of such methods using the program system GAP (Groups, Algorithms, and Programming). Accordingly the workshop will offer both, several series of lectures describing the mathematics underlying the algorithms and their implementations, and exercises at the terminal in applying GAP to group theoretical problems. In detail: There will be 5 such series of lectures, partly in parallel, each of about 8 periods of 45 minutes, on the following topics: - Permutation groups. (A. Seress) - Collecting methods for finitely presented and polycyclic groups. (J. Neubueser and M.F. Newman) - Finitely presented Groups: Coset table methods, Knuth Bendix, Automatic Groups. (D. Holt and J. Neubueser) - Representation theory. (K. Lux and H. Pahlings) - Programming in GAP. (M. Schoenert) In addition we plan 5 exercise classes, three for people with little or no experience in the use of computers in group theory, which will begin with a common introduction to GAP and then separate according to the interest of participants in finite groups, finitely presented groups, or representation theory. Further, there will be one exercise class for people with some experience, which will supplement the lecture series 'Programming in GAP'. While for all these four exercise classes we intend to provide some exercises and problems, finally, mainly in the second part of the week, we intend to run an exercise class 'Bring your own problem', in which we will try to give advice how to use group theoretical software on problems that participants are interested in (with no warranty of success!!). Of course moving between these exercise classes will be possible. A tentative time schedule for the workshop looks as follows: Monday to Thursday: 8.30 - 10.00 in parallel: 'Finitely Presented Groups' and 'Representation Theory'. 10.30 - 12.00 in parallel: 'Collection Methods' and 'Programming in GAP'. 13.30 - 15.00 Permutation Groups. 15.15 - 18.00 Practical exercises. On Friday morning there will be lectures on algorithms drawing from all the various methods, on the use of Computer Algebra systems like MAPLE for generic calculations, and on some new developments for the investigation of matrix groups. Terminals and help with their use will still be available on Friday afternoon. For attending the workshop you should register with 'Groups 1993 Galway/St.Andrews'; no special registration for the workshop is necessary, but please do tick the relevant box in the registration form for 'Groups 1993 Galway/St.Andrews'. The GAP system is available free of charge (including source, the manual and several executables) through anonymous ftp. If you want information about GAP, its availability on various computers, and how to get it, please get the file 'pub/gap/README' from the ftp server 'samson.math.rwth-aachen.de' by logging in as user 'ftp' with your e-mail address as password. If you have any further questions with regard to the workshop, please contact: neubueser@math.rwth-aachen.de (Prof. J. Neubueser, Lehrstuhl D fuer Mathematik, RWTH Aachen, Templergraben 64, D 5100, Aachen, Germany. Tel. +49/241/804543) Joachim Neubueser, Martin Schoenert From pluto@mibtt1.mathematik.uni-stuttgart.de Wed Mar 31 10:19:56 1993 From: pluto@mibtt1.mathematik.uni-stuttgart.de "Martin Wursthorn" Date: Wed, 31 Mar 93 10:19:56 +0200 Subject: Re: [dana@bimacs.cs.biu.ac.il: Loewy Series] > I know that the Loewy series of a group can be computed with the help > of a certain central series (Jennings's thm). > Is there either some feature in GAP which determines this series for a > given group or somebody who already wrote a GAP program for that > purpose? > As for p-groups I have written a GAP procedure to compute the Jennings series of such groups using the fact that it is isomorphic to the Lazard series L_n(G) = \prod_{ip^j \ge n}\gamma_i(G)^{p^j}. The calculations are straightforward in GAP. Furthermore there is a function to test whether a given pc-presentation for the group is compatible with the Jennings series. In this case such a presentation can be used (by a theorem of Jennings) to compute a basis for the group algebra over GF(p), which is compatible with the Loewy series. This approach has been implemented in the SISYPHOS program developped in Stuttgart to investigate characteristic p group algebras of p-groups. It is planned to distribute the program as a GAP shared library. Martin Wursthorn Mathematisches Institut B Universit"at Stuttgart From white@mcs.kent.edu Wed Mar 31 22:58:05 1993 From: white@mcs.kent.edu (Donald White) Date: Wed, 31 Mar 93 22:58:05 +0200 Subject: installation problem Our systems people have tried to install GAP 3.2 on an HP 9000/730 and were unable to get it to compile. They gave me the following message: > Specific problem is we are running hpux 9.0 and they apparently only support > through 8.0. The program compiles without complaint and then hangs and > causes a segmentation fault and dumps core when it runs. Sounds like a > stray pointer... We compiled GAP 3.1 under the old operating system last year with no problem, but it won't compile now either. Any suggestions?? -- Don White