This file contains the mails sent to the GAP forum in April-June 1993. Name Email address Mails Lines Martin Schoenert martin@math.rwth-aachen.de 10 303 Frank Celler fceller@math.rwth-aachen.de 8 218 Joachim Neubueser neubuese@math.rwth-aachen.de 7 368 Alexander Hulpke hulpke@abacus.concordia.ca 5 128 Thomas Breuer sam@math.rwth-aachen.de 4 170 SMTP Daemon smtp@huearn.sztaki.hu 3 480 Goetz Pfeiffer pfeiffer@dmi.ens.fr 3 172 Jacob Hirbawi jcbhrb@cerf.net 2 118 Derek Holt dfh@maths.warwick.ac.uk 2 110 Jaroslav Gurican gurican@alpha.dcs.mff.uniba.cs 2 63 Charley Wright wright@bright.uoregon.edu 2 60 Leonard Soicher l.h.soicher@qmw.ac.uk 2 48 Kay Magaard kaym@math.wayne.edu 2 47 Daniel Ruberman ruberman@binah.cc.brandeis.edu 2 39 David Sibley sibley@math.psu.edu 2 30 Stephan Rosebrock rosebrock@mathematik.uni-frankfurt.dbp.de 2 29 Michael Smith smith@pell.anu.edu.au 2 21 T. P. McDonough tpd@aberystwyth.ac.uk 1 75 Peter Jipsen pjipsen@iastate.edu 1 60 Steve Linton slinton@math.rwth-aachen.de 1 34 John R. Neil neil@dehn.mth.pdx.edu 1 34 A. E. Brouwer aeb@win.tue.nl 1 30 Akihiro Munemasa munemasa@math.sci.kyushu-u.ac.jp 1 24 A. Szczepanski aszczepa@umpa.ens-lyon.fr 1 23 A. Caranti caranti@volterra.cineca.it 1 18 Lewis Stiller stiller@blaze.cs.jhu.edu 1 15 Chad Scherrer scherrc@rosevc.rose-hulman.edu 1 14 Dana-Picard Noah dana@bimacs.cs.biu.ac.il 1 13 Frank Leonard matleonard@bodkin.ucg.ie 1 12 Gary K. Schwartz schwartz@symcom.math.uiuc.edu 1 11 N. S. Mendelsohn mendel@ccu.umanitoba.ca 1 6 Steve Linton sl25@cus.cam.ac.uk 1 4 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@math.rwth-aachen.de Thu Apr 1 12:33:35 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 1 Apr 93 12:33:35 +0200 Subject: hidden treasures Dear GAP-forum, Thierry Dana-Picard's question provoked two immediate replies by Peter Webb and Martin Wursthorn which both stated: I have written GAP routines ... . I enjoyed seeing this, I think it shows that the GAP-forum serves its purpose. However I would like to take this instance to appeal to use the GAP-forum also for informally informing others of the existence of such routines without waiting for a question. This aspect has not been emphazised when the function of the GAP-forum was explained in the README file with the announcement of GAP, but I think as time proceeds there will be more such "hidden treasures" which might be useful for others as well if one knows of them. So please tell in the GAP-forum about routines that you have written (and hopefully are willing to share) as well as about interesting applications. It should be clear that since the GAP-forum is unrefereed this does in no way conflict with formal publications. Joachim Neubueser From neubuese@math.rwth-aachen.de Thu Apr 1 12:55:40 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 1 Apr 93 12:55:40 +0200 Subject: Representation Theory in GAP In his letter Peter Webb writes: > 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. We agree. While character theory (and hence ordinary representation theory) is rather well represented in GAP, working with modular representations is not yet. Note however that there is a link to the MOC system for working with modular characters provided in GAP (see section 42.46 ff, p.679 of the manual). We do intend to extend facilities for working in modular representation theory and we will welcome cooperation with others who have already implemented routines or are implementing routines in this field. We will contact Peter Webb directly but also ask others who are interested to contact us, e.g. Klaus Lux or Herbert Pahlings (lux@math.rwth-aachen.de , pahlings@math.rwth-aachen.de) and we hope that eventually we will be able to provide a good package. Joachim Neubueser From pjipsen@iastate.edu Thu Apr 1 21:27:59 1993 From: pjipsen@iastate.edu "Peter Jipsen" Date: Thu, 1 Apr 93 21:27:59 +0200 Subject: Re: hidden treasures >Dear GAP-forum, > >Thierry Dana-Picard's question provoked two immediate replies by Peter >Webb and Martin Wursthorn which both stated: I have written GAP >routines ... . I enjoyed seeing this, I think it shows that the >GAP-forum serves its purpose. > >However I would like to take this instance to appeal to use the >GAP-forum also for informally informing others of the existence of >such routines without waiting for a question. This aspect has not been >emphazised when the function of the GAP-forum was explained in the >README file with the announcement of GAP, but I think as time proceeds >there will be more such "hidden treasures" which might be useful for >others as well if one knows of them. So please tell in the GAP-forum >about routines that you have written (and hopefully are willing to >share) as well as about interesting applications. It should be clear >that since the GAP-forum is unrefereed this does in no way conflict >with formal publications. > >Joachim Neubueser > Not being very well-versed in group theory, I have used GAP mainly for combinatorial problems and finite relation algebras (including polygroups, hypergraphs and a library of small examples). I find it a very convenient language to write little routines that test conjectures on these finite structures, and recently I have started putting it together as a structured domain. However there is a big difference between code written for private research and a public package with documentation and extensive comments. If other forum members are interested in the areas mentioned above, I will gladly share what I've got. I'm certainly interested in feedback, and on whether other GAP users are applying GAP outside group theory. I realise that the developers are mainly commited to supporting algorithms related to groups, but I think they have come up with a nice, clean development system (and are giving it away free!) that could be a basis for several other areas of abstract algebra and discrete mathematics. Have other users of GAP implemented algorithms and structures for universal algebra or related areas? At this point I am only aware of GRAPE by Leonard Soicher for graphs. Some of my routines would greatly benefit from his approach but at the moment small finite polygroups are represented by a domain that contains a list of all elements (records) and an operation table. Most simple minded algorithms in this area loop of all subsets of elements, so the complexity very bad and they won't work for larger structures anyway. Relations are implemented as boolean matrices, but it is simple to convert them to GRAPE format and then use the interface to Brendan McKay's 'nauty' to get a more compact description of the relation. In the near future I will also interface to some c-code of my own, that searches for finite counter examples and applies some theorem proving techniques for relation algebras. BTW does anyone know of a program that tests finitary relational structures for isomorphism (e.g. nauty does it for binary relational structures)? Peter Jipsen From sl25@cus.cam.ac.uk Fri Apr 2 14:09:21 1993 From: sl25@cus.cam.ac.uk "Steve Linton" Date: Fri, 2 Apr 93 14:09:21 +0200 Subject: Executables and upgrade to 3r2p1 Are the executables on samson yet upgraded to 3r2p1? Steve From neubuese@math.rwth-aachen.de Fri Apr 2 14:29:18 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Fri, 2 Apr 93 14:29:18 +0200 Subject: Re: Executables and upgrade to 3r2p1 Steve Linton asks: > Are the executables on samson yet upgraded to 3r2p1? > > Steve The answer is: No, not yet. But patch 1 contains only minimal changes in the kernel. Joachim Neubueser (for Martin who knows such things better than I) From rosebrock@mathematik.uni-frankfurt.dbp.de Sat Apr 10 14:12:48 1993 From: rosebrock@mathematik.uni-frankfurt.dbp.de "Stephan Rosebrock" Date: Sat, 10 Apr 93 14:12:48 +0200 Subject: maps of fin pres into symmetric groups Dear Gap-Forum, I don't have much experience in GAP, but I would be intersted in a function that tests, if there is a homomorphism of a group, given as a finite presentation, into a given symmetric or alternating group. Stephan Rosebrock rosebro@math.uni-frankfurt.de From jcbhrb@cerf.net Mon Apr 12 12:17:46 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Mon, 12 Apr 93 12:17:46 +0200 Subject: RE: maps of fin pres groups into symmetric groups Stephan Rosebrock writes: > I don't have much experience in GAP, but I would be intersted in a > function that tests, if there is a homomorphism of a group, given as a > finite presentation, into a given symmetric or alternating group. I don't have much experience myself but I would like to offer a few suggestions since the problem of calculating Hom(G,H) for arbitrary groups G,H is a fundementally important one. First since there is always a trivial hom from any group to another; I will assume that the search is for a nontrivial one or perhaps for a monic one; since Stephan used "into a given ..." instead of "to a given ..." I will assume that the latter case is the one of interest. At any rate in the case of the symmetric group there is a systematic way to find all hom's and a way to extract the monic ones. GAP does have functions that reduce this problem to a simple combinatorial one : first calculate the marks of your group using TableOfMarks; then to find all hom's from your group to the symmetric of degree n you find all possible ways you can add the rows of the table of marks so the first entry equals n; of this list in the monic ones n only occurs as the first entry. This is in complete ananlogy of finding all possible representations (faithful or not) of a given group into GL(n,C) -- simply replace "table of marks" for "character table" and "degree" for "dimension". In fact a generic program that takes in a matrix and finds all possible combination of its rows have n as the first entry and then checks if n does not occur as another entry will work for both. It would be nice if someone can write such a program in GAP; in the meantime for low degrees (or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult: Here's an example with a group defined by the presentation : a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); AbsGroup1 := Group(a,b,c,z); AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2]; The table of marks and character tables are then : Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord])); Marks1 := MatTom( TableOfMarks( Group1 ) ); Charachters1 := CharTable( Group1 ).irreducibles; Marks1; [ [ 24, 0, 0, 0, 0, 0, 0 ], [ 12, 12, 0, 0, 0, 0, 0 ], [ 8, 0, 2, 0, 0, 0, 0 ], [ 6, 6, 0, 2, 0, 0, 0 ], [ 4, 4, 1, 0, 1, 0, 0 ], [ 3, 3, 0, 3, 0, 3, 0 ], [ 1, 1, 1, 1, 1, 1, 1 ] ] All hom's from the group to Symmetric(8) for example correspond to [ 8, 0, 2, 0, 0, 0, 0 ], M[3] [ 8, 8, 2, 4, 2, 2, 2 ], M[4] + 2 M[7] [ 8, 8, 2, 0, 2, 0, 0 ], 2 M[5] [ 8, 8, 2, 4, 2, 4, 1 ], M[5] + M[6] + M[7] [ 8, 8, 5, 4, 5, 4, 4 ], M[5] + 4 M[7] [ 8, 8, 2, 8, 2, 6, 8 ], 2 M[6] + 2 M[7] [ 8, 8, 5, 8, 5, 8, 5 ], M[6] + 5 M[7] [ 8, 8, 8, 8, 8, 8, 8 ], 8 M[7] so there are 8 inequivalent hom's; only the first is monic. Chracters1; [ [ 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ], [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ], [ 2, 0, 1, 1, -2, -1, -1 ], [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ], [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ], [ 3, -1, 0, 0, 3, 0, 0 ] ] (I was going to do a similar calculations with the character table of the group for comparison but there are too many possibilities even for GL(3,C) -- oh well, I should have picked a simpler group!) Hope this helps. Jacob Hirbawi JcbHrb@CERF.net From smtp@huearn.sztaki.hu Mon Apr 12 12:39:31 1993 From: smtp@huearn.sztaki.hu "SMTP Daemon" Date: Mon, 12 Apr 93 12:39:31 +0200 Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 12:44:20 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 12:44:26 Subject: RE: maps of fin pres groups into symmetric groups From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 12:36:10 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12 Apr 93 12:18:42 +0200 Date: Mon, 12 Apr 93 12:18:42 +0200 Message-ID: <9304112130.AA15242@nic.cerf.net> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: Jacob Hirbawi To: Multiple recipients of list Subject: RE: maps of fin pres groups into symmetric groups Stephan Rosebrock writes: > I don't have much experience in GAP, but I would be intersted in a > function that tests, if there is a homomorphism of a group, given as a > finite presentation, into a given symmetric or alternating group. I don't have much experience myself but I would like to offer a few suggestions since the problem of calculating Hom(G,H) for arbitrary groups G,H is a fundementally important one. First since there is always a trivial hom from any group to another; I will assume that the search is for a nontrivial one or perhaps for a monic one; since Stephan used "into a given ..." instead of "to a given ..." I will assume that the latter case is the one of interest. At any rate in the case of the symmetric group there is a systematic way to find all hom's and a way to extract the monic ones. GAP does have functions that reduce this problem to a simple combinatorial one : first calculate the marks of your group using TableOfMarks; then to find all hom's from your group to the symmetric of degree n you find all possible ways you can add the rows of the table of marks so the first entry equals n; of this list in the monic ones n only occurs as the first entry. This is in complete ananlogy of finding all possible representations (faithful or not) of a given group into GL(n,C) -- simply replace "table of marks" for "character table" and "degree" for "dimension". In fact a generic program that takes in a matrix and finds all possible combination of its rows have n as the first entry and then checks if n does not occur as another entry will work for both. It would be nice if someone can write such a program in GAP; in the meantime for low degrees (or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult: Here's an example with a group defined by the presentation : a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); AbsGroup1 := Group(a,b,c,z); AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2]; The table of marks and character tables are then : Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord])); Marks1 := MatTom( TableOfMarks( Group1 ) ); Charachters1 := CharTable( Group1 ).irreducibles; Marks1; [ [ 24, 0, 0, 0, 0, 0, 0 ], [ 12, 12, 0, 0, 0, 0, 0 ], [ 8, 0, 2, 0, 0, 0, 0 ], [ 6, 6, 0, 2, 0, 0, 0 ], [ 4, 4, 1, 0, 1, 0, 0 ], [ 3, 3, 0, 3, 0, 3, 0 ], [ 1, 1, 1, 1, 1, 1, 1 ] ] All hom's from the group to Symmetric(8) for example correspond to [ 8, 0, 2, 0, 0, 0, 0 ], M[3] [ 8, 8, 2, 4, 2, 2, 2 ], M[4] + 2 M[7] [ 8, 8, 2, 0, 2, 0, 0 ], 2 M[5] [ 8, 8, 2, 4, 2, 4, 1 ], M[5] + M[6] + M[7] [ 8, 8, 5, 4, 5, 4, 4 ], M[5] + 4 M[7] [ 8, 8, 2, 8, 2, 6, 8 ], 2 M[6] + 2 M[7] [ 8, 8, 5, 8, 5, 8, 5 ], M[6] + 5 M[7] [ 8, 8, 8, 8, 8, 8, 8 ], 8 M[7] so there are 8 inequivalent hom's; only the first is monic. Chracters1; [ [ 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ], [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ], [ 2, 0, 1, 1, -2, -1, -1 ], [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ], [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ], [ 3, -1, 0, 0, 3, 0, 0 ] ] (I was going to do a similar calculations with the character table of the group for comparison but there are too many possibilities even for GL(3,C) -- oh well, I should have picked a simpler group!) Hope this helps. Jacob Hirbawi JcbHrb@CERF.net From smtp@huearn.sztaki.hu Mon Apr 12 12:58:39 1993 From: smtp@huearn.sztaki.hu "SMTP Daemon" Date: Mon, 12 Apr 93 12:58:39 +0200 Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 13:04:26 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:04:42 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 13:04:36 Subject: Undeliverable Mail From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 12:55:14 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA21090 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:54:45 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA11211; Mon, 12 Apr 93 12:47:15 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21251; Mon, 12 Apr 93 12:48:05 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24980; Mon, 12 Apr 93 12:39:59 +0200 Date: Mon, 12 Apr 93 12:39:59 +0200 Message-ID: <9304121039.AA24980@samson.math.rwth-aachen.de> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: To: Multiple recipients of list Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 12:44:20 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 12:44:26 Subject: RE: maps of fin pres groups into symmetric groups From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 12:36:10 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12 Apr 93 12:18:42 +0200 Date: Mon, 12 Apr 93 12:18:42 +0200 Message-ID: <9304112130.AA15242@nic.cerf.net> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: Jacob Hirbawi To: Multiple recipients of list Subject: RE: maps of fin pres groups into symmetric groups Stephan Rosebrock writes: > I don't have much experience in GAP, but I would be intersted in a > function that tests, if there is a homomorphism of a group, given as a > finite presentation, into a given symmetric or alternating group. I don't have much experience myself but I would like to offer a few suggestions since the problem of calculating Hom(G,H) for arbitrary groups G,H is a fundementally important one. First since there is always a trivial hom from any group to another; I will assume that the search is for a nontrivial one or perhaps for a monic one; since Stephan used "into a given ..." instead of "to a given ..." I will assume that the latter case is the one of interest. At any rate in the case of the symmetric group there is a systematic way to find all hom's and a way to extract the monic ones. GAP does have functions that reduce this problem to a simple combinatorial one : first calculate the marks of your group using TableOfMarks; then to find all hom's from your group to the symmetric of degree n you find all possible ways you can add the rows of the table of marks so the first entry equals n; of this list in the monic ones n only occurs as the first entry. This is in complete ananlogy of finding all possible representations (faithful or not) of a given group into GL(n,C) -- simply replace "table of marks" for "character table" and "degree" for "dimension". In fact a generic program that takes in a matrix and finds all possible combination of its rows have n as the first entry and then checks if n does not occur as another entry will work for both. It would be nice if someone can write such a program in GAP; in the meantime for low degrees (or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult: Here's an example with a group defined by the presentation : a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); AbsGroup1 := Group(a,b,c,z); AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2]; The table of marks and character tables are then : Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord])); Marks1 := MatTom( TableOfMarks( Group1 ) ); Charachters1 := CharTable( Group1 ).irreducibles; Marks1; [ [ 24, 0, 0, 0, 0, 0, 0 ], [ 12, 12, 0, 0, 0, 0, 0 ], [ 8, 0, 2, 0, 0, 0, 0 ], [ 6, 6, 0, 2, 0, 0, 0 ], [ 4, 4, 1, 0, 1, 0, 0 ], [ 3, 3, 0, 3, 0, 3, 0 ], [ 1, 1, 1, 1, 1, 1, 1 ] ] All hom's from the group to Symmetric(8) for example correspond to [ 8, 0, 2, 0, 0, 0, 0 ], M[3] [ 8, 8, 2, 4, 2, 2, 2 ], M[4] + 2 M[7] [ 8, 8, 2, 0, 2, 0, 0 ], 2 M[5] [ 8, 8, 2, 4, 2, 4, 1 ], M[5] + M[6] + M[7] [ 8, 8, 5, 4, 5, 4, 4 ], M[5] + 4 M[7] [ 8, 8, 2, 8, 2, 6, 8 ], 2 M[6] + 2 M[7] [ 8, 8, 5, 8, 5, 8, 5 ], M[6] + 5 M[7] [ 8, 8, 8, 8, 8, 8, 8 ], 8 M[7] so there are 8 inequivalent hom's; only the first is monic. Chracters1; [ [ 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ], [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ], [ 2, 0, 1, 1, -2, -1, -1 ], [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ], [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ], [ 3, -1, 0, 0, 3, 0, 0 ] ] (I was going to do a similar calculations with the character table of the group for comparison but there are too many possibilities even for GL(3,C) -- oh well, I should have picked a simpler group!) Hope this helps. Jacob Hirbawi JcbHrb@CERF.net From smtp@huearn.sztaki.hu Mon Apr 12 13:09:39 1993 From: smtp@huearn.sztaki.hu "SMTP Daemon" Date: Mon, 12 Apr 93 13:09:39 +0200 Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 13:14:29 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:14:46 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 13:14:41 Subject: Undeliverable Mail From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 13:13:45 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA21365 (5.65b/CWI-2.216); Mon, 12 Apr 1993 13:13:16 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA11719; Mon, 12 Apr 93 13:06:34 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21296; Mon, 12 Apr 93 13:07:15 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA25050; Mon, 12 Apr 93 12:59:00 +0200 Date: Mon, 12 Apr 93 12:59:00 +0200 Message-ID: <9304121059.AA25050@samson.math.rwth-aachen.de> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: To: Multiple recipients of list Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 13:04:26 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 13:04:42 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 13:04:36 Subject: Undeliverable Mail From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 12:55:14 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA21090 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:54:45 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA11211; Mon, 12 Apr 93 12:47:15 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21251; Mon, 12 Apr 93 12:48:05 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24980; Mon, 12 Apr 93 12:39:59 +0200 Date: Mon, 12 Apr 93 12:39:59 +0200 Message-ID: <9304121039.AA24980@samson.math.rwth-aachen.de> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: To: Multiple recipients of list Subject: Undeliverable Mail HUEARN.SZTAKI.HU unable to deliver following mail to recipient(s): HUEARN.SZTAKI.HU received negative reply: 550 ... User unknown ** Text of Mail follows ** Received: from vella.sztaki.hu by HUEARN.SZTAKI.HU (IBM VM SMTP V2R2) with TCP; Mon, 12 Apr 93 12:44:20 SET Received: by vella.sztaki.hu (MX V3.2) with SITE; Mon, 12 Apr 1993 12:44:31 gmt+1 Received: via VELLA (2.0) from: uucp>gap-forum@samson.math.rwth-aachen.de at 93-04-12 12:44:26 Subject: RE: maps of fin pres groups into symmetric groups From: gap-forum@samson.math.rwth-aachen.de To: ehorvath@math.rwth-aachen.de Received: from mcsun.EU.net by HUGBOX.SZTAKI.HU (MX V3.2) with SMTP; Mon, 12 Apr 1993 12:36:10 gmt+1 Received: from urmel.Informatik.RWTH-Aachen.DE by mcsun.EU.net with SMTP id AA20890 (5.65b/CWI-2.216); Mon, 12 Apr 1993 12:35:41 +0200 Received: from math.math.rwth-aachen.de by urmel.informatik.rwth-aachen.de (4.1/urmel-5) id AA10807; Mon, 12 Apr 93 12:26:26 +0200 Received: from samson.math.rwth-aachen.de by math.math.rwth-aachen.de with SMTP (15.11/15.6) id AA21211; Mon, 12 Apr 93 12:27:15 mes Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C) id AA24879; Mon, 12 Apr 93 12:18:42 +0200 Date: Mon, 12 Apr 93 12:18:42 +0200 Message-ID: <9304112130.AA15242@nic.cerf.net> Comment: GAP Forum Originator: gap-forum@samson.math.rwth-aachen.de Errors-To: martin@samson.math.rwth-aachen.de Reply-To: Sender: gap-forum@samson.math.rwth-aachen.de Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas From: Jacob Hirbawi To: Multiple recipients of list Subject: RE: maps of fin pres groups into symmetric groups Stephan Rosebrock writes: > I don't have much experience in GAP, but I would be intersted in a > function that tests, if there is a homomorphism of a group, given as a > finite presentation, into a given symmetric or alternating group. I don't have much experience myself but I would like to offer a few suggestions since the problem of calculating Hom(G,H) for arbitrary groups G,H is a fundementally important one. First since there is always a trivial hom from any group to another; I will assume that the search is for a nontrivial one or perhaps for a monic one; since Stephan used "into a given ..." instead of "to a given ..." I will assume that the latter case is the one of interest. At any rate in the case of the symmetric group there is a systematic way to find all hom's and a way to extract the monic ones. GAP does have functions that reduce this problem to a simple combinatorial one : first calculate the marks of your group using TableOfMarks; then to find all hom's from your group to the symmetric of degree n you find all possible ways you can add the rows of the table of marks so the first entry equals n; of this list in the monic ones n only occurs as the first entry. This is in complete ananlogy of finding all possible representations (faithful or not) of a given group into GL(n,C) -- simply replace "table of marks" for "character table" and "degree" for "dimension". In fact a generic program that takes in a matrix and finds all possible combination of its rows have n as the first entry and then checks if n does not occur as another entry will work for both. It would be nice if someone can write such a program in GAP; in the meantime for low degrees (or dimenions) calculations by HAND( v3.2 or above ;-) ) are not too difficult: Here's an example with a group defined by the presentation : a := AbstractGenerator("a"); b := AbstractGenerator("b"); c := AbstractGenerator("c"); z := AbstractGenerator("z"); AbsGroup1 := Group(a,b,c,z); AbsGroup1.relators := [a^2*z^-1,b^3*z^-1,c^3*z^-1,a*b*c*z^-1,z^2]; The table of marks and character tables are then : Group1 := OperationCosetsFpGroup(g1,Subgroup(AbsGroup1,[IdWord])); Marks1 := MatTom( TableOfMarks( Group1 ) ); Charachters1 := CharTable( Group1 ).irreducibles; Marks1; [ [ 24, 0, 0, 0, 0, 0, 0 ], [ 12, 12, 0, 0, 0, 0, 0 ], [ 8, 0, 2, 0, 0, 0, 0 ], [ 6, 6, 0, 2, 0, 0, 0 ], [ 4, 4, 1, 0, 1, 0, 0 ], [ 3, 3, 0, 3, 0, 3, 0 ], [ 1, 1, 1, 1, 1, 1, 1 ] ] All hom's from the group to Symmetric(8) for example correspond to [ 8, 0, 2, 0, 0, 0, 0 ], M[3] [ 8, 8, 2, 4, 2, 2, 2 ], M[4] + 2 M[7] [ 8, 8, 2, 0, 2, 0, 0 ], 2 M[5] [ 8, 8, 2, 4, 2, 4, 1 ], M[5] + M[6] + M[7] [ 8, 8, 5, 4, 5, 4, 4 ], M[5] + 4 M[7] [ 8, 8, 2, 8, 2, 6, 8 ], 2 M[6] + 2 M[7] [ 8, 8, 5, 8, 5, 8, 5 ], M[6] + 5 M[7] [ 8, 8, 8, 8, 8, 8, 8 ], 8 M[7] so there are 8 inequivalent hom's; only the first is monic. Chracters1; [ [ 1, 1, 1, 1, 1, 1, 1 ], [ 1, 1, E(3)^2, E(3), 1, E(3)^2, E(3) ], [ 1, 1, E(3), E(3)^2, 1, E(3), E(3)^2 ], [ 2, 0, 1, 1, -2, -1, -1 ], [ 2, 0, E(3), E(3)^2, -2, -E(3), -E(3)^2 ], [ 2, 0, E(3)^2, E(3), -2, -E(3)^2, -E(3) ], [ 3, -1, 0, 0, 3, 0, 0 ] ] (I was going to do a similar calculations with the character table of the group for comparison but there are too many possibilities even for GL(3,C) -- oh well, I should have picked a simpler group!) Hope this helps. Jacob Hirbawi JcbHrb@CERF.net From neubuese@math.rwth-aachen.de Tue Apr 13 11:41:26 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 13 Apr 93 11:41:26 +0200 Subject: re. maps of f.p. groups into symmetric groups Stephan Rosebrock asked for a function that tests if there is a homomorphism of a finitely presented group into a given symmetric (or alternating) group. Jacob Hirbawi explained, how to use the table of marks of the finitely presented group for this task. This will of course only work if the finitely presented group is also finite (and not too big) so that GAP can calculate its table of marks, but then it is a nice method. However there is also a method to find permutation representations of a finitely presented group of a given (not too big) degree (i.e. homomorhisms into a given symmetric group of not too big degree), which does not at all assume that the finitely presented group is finite, namely the so-called Low Index Method which is implemented in GAP by the function LowIndexSubgroupsFpGroup, described in section 22.6, page 419 of the manual of GAP 3. The practical limitation of the degree for which the method will work depends strongly on the number of generators of the finitely presented group but it has proved a rather useful tool for the investigation of several finitely presented groups that appeared in the literature. If wanted I can provide some references. Joachim Neubueser From rosebrock@mathematik.uni-frankfurt.dbp.de Wed Apr 14 11:25:08 1993 From: rosebrock@mathematik.uni-frankfurt.dbp.de "Stephan Rosebrock" Date: Wed, 14 Apr 93 11:25:08 +0200 Subject: Re: maps of fin pres into symmetric groups Thank you, Jacob, for your help with homomorphisms in GAP. I have still some questions: You are right, I am not only interested in injective homomorphisms, but rather all of them. My problem is that the groups where I look for homomorphic images are not finite. The groups are finitely generated and all relators have the form: a b = b c for generators a,b,c. But there is certainly still an algorithm for detecting all homomorphic images of such a group G to a given symmetric group S: There are only finitely many possibilities in mapping the generators of G to the generators of S and one such possibility describes a map entirely. I could not get the example Jacob sent to work, because the group g1 was not defined. Stephan Rosebrock rosebro@math.uni-frankfurt.de From dfh@maths.warwick.ac.uk Wed Apr 14 13:46:55 1993 From: dfh@maths.warwick.ac.uk "Derek Holt" Date: Wed, 14 Apr 93 13:46:55 +0200 Subject: Re: maps of fin pres into symmetric groups > > Dear Gap-Forum, > > I don't have much experience in GAP, but I would be intersted in a > function that tests, if there is a homomorphism of a group, given as a > finite presentation, into a given symmetric or alternating group. > > Stephan Rosebrock > > rosebro@math.uni-frankfurt.de > > It seems to me that finding homomorphisms of s finitely presented group G into the symmetric group of degree n is almost precisely equivalent to the LowIndexSubgroupsFpGroup function. The call LowIndexSubgroupsFpGroup( G, TrivialSubgroup(G), n ) returns a list of representatives of all conjugacy classes of subgroups of G of index at most n. (In general, you get all subgroups that contain the subgroup specified by the second argument.) Then a conjugacy class of subgroups of G of index m, corresponds to an equivalence class of homomorphisms from G to a transitive subgroup of the symmetric group of degree m, where two homomorphisms are regarded as equivalent if they are the same after renumbering the points being permuted. To get the corresponding homomorphisms explicitly, I think you probably have to use the CosetTableFpGroup (Todd-Coxeter) function. Here is a complete example - homomorphisms of the Von Dyck 237-group into the symmetric group of degree 10. a := AbstractGenerator("a"); b := AbstractGenerator("b"); G237 := Group(a,b); G237.relators := [a^2, b^3, (a*b)^7 ]; sublist := LowIndexSubgroupsFpGroup( G237, TrivialSubgroup(G237), 10 ); imlist := []; for gp in sublist do ct := CosetTableFpGroup( G237, gp ); Add( imlist, List(ct,PermList) ); od; After this, imlist contains 4 elements, corresponding to four equivalence classes of homomorphisms. Each of these contains the images of the generators and their inverses under that homomorphism. (The images are respectively the trivial group, PSL(2,7) of degree 7 twice, PSL(2,8) of degree 9, and PSL(2,7) of degree 8.) [ [ (), (), (), () ], [ (3,4)(6,7), (3,4)(6,7), (1,2,3)(4,5,6), (1,3,2)(4,6,5) ], [ (3,4)(5,6), (3,4)(5,6), (1,2,3)(4,5,7), (1,3,2)(4,7,5) ], [ (2,3)(4,6)(5,7)(8,9), (2,3)(4,6)(5,7)(8,9), (1,2,4)(3,5,7)(6,8,9), (1,4,2)(3,7,5)(6,9,8) ], [ (1,2)(3,4)(5,6)(7,8), (1,2)(3,4)(5,6)(7,8), (2,3,5)(6,7,8), (2,5,3)(6,8,7) ] ] Derek Holt. From martin@math.rwth-aachen.de Wed Apr 14 14:34:22 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Wed, 14 Apr 93 14:34:22 +0200 Subject: Re: Undeliverable Mail My apologies to everybody for the mail loop. I think we have everything under control again. I am not absolutely certain, because I am still trying to figure out what went wrong. It seems like three or four small problems collaborated to create this terrible mess. 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@math.rwth-aachen.de Wed Apr 14 14:36:56 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Wed, 14 Apr 93 14:36:56 +0200 Subject: Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2) This is to announce the availibility of the second upgrade for GAP 3.2. This upgrade brings version 3 release 2 patchlevel 1 (V3R2P1) to version 3 release 2 patchlevel 2 (V3R2P2). The priority of this upgrade is medium. The upgrade is available as file 'upg3r2p2.dif.Z' on the 'ftp' server 'samson.math.rwth-aachen.de'. It should be available on the other 'ftp' servers soon. Again I do not send out this upgrade as e-mail, it is again quite large (about 40 KBytes 'compress'-ed). First unpack the upgrade with 'uncompress upg3r1p2.dif.Z'. Then read the beginning of the unpacked file 'upg3r2p2.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 fceller@math.rwth-aachen.de Wed Apr 14 16:16:39 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Wed, 14 Apr 93 16:16:39 +0200 Subject: Re: Undeliverable Mail Apologies to everyone who get this message twice, there was still a small problem in our list server, which is now hopefully fixed. best wishes Frank ----------------------------------------------------------------------------- My apologies to everybody for the mail loop. I think we have everything under control again. I am not absolutely certain, because I am still trying to figure out what went wrong. It seems like three or four small problems collaborated to create this terrible mess. 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@math.rwth-aachen.de Wed Apr 14 16:28:53 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Wed, 14 Apr 93 16:28:53 +0200 Subject: Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2) Apologies to everyone who get this message twice, there was still a small problem in our list server, which is now hopefully fixed. best wishes Frank ----------------------------------------------------------------------------- This is to announce the availibility of the second upgrade for GAP 3.2. This upgrade brings version 3 release 2 patchlevel 1 (V3R2P1) to version 3 release 2 patchlevel 2 (V3R2P2). The priority of this upgrade is medium. The upgrade is available as file 'upg3r2p2.dif.Z' on the 'ftp' server 'samson.math.rwth-aachen.de'. It should be available on the other 'ftp' servers soon. Again I do not send out this upgrade as e-mail, it is again quite large (about 40 KBytes 'compress'-ed). First unpack the upgrade with 'uncompress upg3r1p2.dif.Z'. Then read the beginning of the unpacked file 'upg3r2p2.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 sibley@math.psu.edu Wed Apr 14 17:59:26 1993 From: sibley@math.psu.edu "David Sibley" Date: Wed, 14 Apr 93 17:59:26 +0200 Subject: Re: Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2) Another patch? I still haven't managed to get the first one. There is nothing at dimacs.rutgers.edu except old versions of GAP. All the files in the gap directory there have 1992 dates. Last time I managed to connect to wuarchive.wustl.edu, about a week ago, the first patch still was not there. wustl is usually not available during normal hours because its limit for anonymous logins (175 users, which is very liberal, I think) is full. I haven't checked the machine in California. I think that's the one I always have trouble with, because it generates gigantic directory listings. Where are people in the US or Canada getting these patches from? From neil@dehn.mth.pdx.edu Thu Apr 15 07:36:57 1993 From: neil@dehn.mth.pdx.edu "John R. Neil" Date: Thu, 15 Apr 93 07:36:57 +0200 Subject: Re: Upgrade for GAP 3.2 patchlevel 1 (V3R2P1) to patchlevel 2 (V3R2P2) In message <9304141604.AA04962@frobenius.math.psu.edu> you write: >Another patch? I still haven't managed to get the first one. There is >nothing at dimacs.rutgers.edu except old versions of GAP. All the >files in the gap directory there have 1992 dates. > >Last time I managed to connect to wuarchive.wustl.edu, about a week >ago, the first patch still was not there. wustl is usually not >available during normal hours because its limit for anonymous logins >(175 users, which is very liberal, I think) is full. > >I haven't checked the machine in California. I think that's the one I >always have trouble with, because it generates gigantic directory >listings. > >Where are people in the US or Canada getting these patches from? > > In case anyone is interested, I've begun using an automatic mirroring shell which, every night, updates my copies of everything on samson relating to GAP. This mirror is available via anonymous ftp from . Those in the US are welcome to use this site as an alternative source of GAP code. --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 matleonard@bodkin.ucg.ie Mon Apr 19 18:35:39 1993 From: matleonard@bodkin.ucg.ie "Frank Leonard" Date: Mon, 19 Apr 93 18:35:39 +0200 Subject: Re: your mail I have been attempting some constuctions of finite groups in GAP as defined by a presentation in abstract generators/relators. The problem consists of applying a certain algorithim to constuct a group which I then attempt to identify. I also have access to the C.A. package CAYLEY and have re-written the algorithim for CAYLEY. I have found CAYLEY to be vastly superior (time wise) to GAP for this problem. I assume that the fact that GAP programs/functions are interpreted would be significant in explaining the performance discrepancies but I am curious if there are any other factors which might be significant. Can you tell me if there are any plans at present to write a compiler for GAP? From neubuese@math.rwth-aachen.de Tue Apr 20 17:10:54 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 20 Apr 93 17:10:54 +0200 Subject: Re: your mail Frank Leonard writes: > I have been attempting some constuctions of finite groups in GAP as > defined by a presentation in abstract generators/relators. > The problem consists of applying a certain algorithim to constuct a > group which I then attempt to identify. I also have access to the C.A. > package CAYLEY and have re-written the algorithim for CAYLEY. I have > found CAYLEY to be vastly superior (time wise) to GAP for this problem. > I assume that the fact that GAP programs/functions are interpreted > would be significant in explaining the performance discrepancies but I > am curious if there are any other factors which might be significant. > Can you tell me if there are any plans at present to write a compiler > for GAP? I am sorry that we cannot really answer such an unspecified (but nevertheless very critical) letter, much as we try to react to criticism brought to our attention in the GAP-forum (or otherwise). Frank Leonard has not told us what kind of problem he is really looking at, nor which GAP functions he has used, nor even which version of GAP. There are of course functions for which the fact that they are interpreted rather than originally written in C and compiled mean a loss of efficiency. We know that this can in particular be the case with functions which deal in a rather combinatorial way with small data, as is the case with many functions handling presentations. For this reason some of the functions for dealing with presentations have parts in the kernel to circumvent this difficulty. If the interpretation of GAP functions was the reason for inefficiency that Frank Leonard has observed then it would be helpful for us to know, *how* big the loss of efficiency was in his case for which functions, e.g. in comparison with CAYLEY. It is not helpful just to be told that CAYLEY was *vastly* superior for some function(s?) that are not named applying "a certain algorithm" that he does not care to tell us about. It is also likely that for certain functions we are using genuinly worse methods than CAYLEY (for others we may use better ones). Then we want to know even more where this is the case in order to be able to improve them. We are not only open to but ask for constructive or at least well specified criticism, but I must say that a letter like that of Frank Leonard is not only unhelpful but rather discouraging. Joachim Neubueser PS. I have said already in a previous letter to the GAP-forum that the idea to develop a compiler for GAP is being considered, but that, if at all, a compiler cannot be expected in the nearer foreseeable future. From ruberman@binah.cc.brandeis.edu Wed Apr 21 18:08:48 1993 From: ruberman@binah.cc.brandeis.edu "Daniel Ruberman" date: Wed, 21 Apr 93 18:08:48 +0200 Subject: AbelianInvariants I am somewhat confused by the output from the AbelianInvariants function, as applied to a finitely generated abelian group. I am using GAP 3.2 with upgrades 1 and 2, on a DEC Ultrix workstation, if it matters. In the example below, I hoped to get the output [0 0], corresponding to the fact that the abelianization of the free group on two letters ("a" and "b" below) is Z+Z. Have I misused the function or misinterpreted the output? Daniel Ruberman ruberman@binah.cc.brandeis.edu gap> a:=AbstractGenerator("a"); a gap> b:=AbstractGenerator("b"); b gap> G:=Group(a,b); Group( a, b ) gap> G.relators:=[]; [ ] gap> H:=CommutatorFactorGroup(G); Group( c.1, c.2 ) gap> H.relators; [ c.1^-1*c.2^-1*c.1*c.2 ] gap> AbelianInvariants(H); [ 0 ] From martin@math.rwth-aachen.de Wed Apr 21 19:09:32 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Wed, 21 Apr 93 19:09:32 +0200 Subject: Re: AbelianInvariants Daniel Ruberman writes in his e-mail message of 1993/04/21 I am somewhat confused by the output from the AbelianInvariants function, as applied to a finitely generated abelian group. I am using GAP 3.2 with upgrades 1 and 2, on a DEC Ultrix workstation, if it matters. In the example below, I hoped to get the output [0 0], corresponding to the fact that the abelianization of the free group on two letters ("a" and "b" below) is Z+Z. Have I misused the function or misinterpreted the output? gap> a:=AbstractGenerator("a");; gap> b:=AbstractGenerator("b"); gap> G:=Group(a,b);; gap> G.relators:=[];; gap> H:=CommutatorFactorGroup(G);; gap> AbelianInvariants(H); [ 0 ] No, this is a genuine bug. If the number of relators of the commutator factor group is less than the number of generators, 'AbelianInvariants' will drop infinite components. Now the commutator factor group of a group on $n$ generators has at least $n(n-1)/2$ relators (namely the commutators), so the problem can only occur for the free group on 2 generators. BTW, 'AbelianInvariants' for finitely presented groups has two more problems. It gives an error when applied to the free group on one generator. It returns a list $l$ such that $h = Z/l[1]Z * Z/l[2]Z * Z/l[3]Z ... $, but the elements are such that $l[1] | l[2] | l[3] ... $ (this is usually called the Smith normal form, or elementary divisors). On the other hand the description of 'AbelianInvariants' states that the $l[i]$ shall all be prime powers (this is usually called primary decomposition). It is of course easy to convert between those two representations. All three problems shall be fixed in the next upgrade. Then it will also be allowed to apply 'AbelianInvariants' to arbitrary groups, not just abelian ones (allowing one to bypass the computation of the commutator factor group, which can be costly for finitely presented groups with many generators). 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 ruberman@binah.cc.brandeis.edu Thu Apr 22 14:22:15 1993 From: ruberman@binah.cc.brandeis.edu "Daniel Ruberman" date: Thu, 22 Apr 93 14:22:15 +0200 Subject: GroupHomomorphismByImages Are there any plans to implement the command GroupHomomorphismByImages for homomorphisms of Finitely Presented groups to, say, permutation groups? There is no theoretical obstruction to doing so, as it is a matter of checking whether the images of the relators in the permutation group are all trivial. Failing that, if anyone has written GAP routines to accomplish this task, could they please let me know. Thanks, Daniel Ruberman (ruberman@binah.cc.brandeis.edu) From sibley@math.psu.edu Sun Apr 25 18:51:15 1993 From: sibley@math.psu.edu "David Sibley" Date: Sun, 25 Apr 93 18:51:15 +0200 Subject: Subgroup(Parent(g),elts) I just discovered an oddity in GAP and am trying to figure out why it is the way it is: Subgroup(g,elts) works only when g is a parent group. As far as I can see, this means that when I write programs, where I don't know whether g is going to be a parent group or not, I should actually use Subgroup(Parent(g),elts) instead of the above. But why does Subgroup not automatically use the parent of g, if that's what it needs, rather than making me explicitly say to use it? Or am I going to get into trouble using Subgroup(Parent(g),elts)? David Sibley | "Accurate reckoning. The entrance into knowledge Amateur radio NT3O | of all existing things and all obscure secrets." sibley@math.psu.edu | -- The Rhind Papyrus From martin@math.rwth-aachen.de Mon Apr 26 12:53:57 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Mon, 26 Apr 93 12:53:57 +0200 Subject: Re: GroupHomomorphismByImages Daniel Ruberman writes in his e-mail message of 1993/04/22 Are there any plans to implement the command GroupHomomorphismByImages for homomorphisms of Finitely Presented groups to, say, permutation groups? Which version of GAP do you use. In GAP 3.2 you can do the following gap> g := FreeGroup( 2, "g" );; gap> g.relators := [ g.1^2, g.2^5, (g.1*g.2^-1)^3 ];; gap> h := Group( (1,2)(3,4), (1,2,3,4,5) );; gap> f := GroupHomomorphismByImages( g, h, g.generators, h.generators );; gap> IsHomomorphism( f ); true gap> PreImages( f, SylowSubgroup( h, 2 ) ); Subgroup( Group( g.1, g.2 ), [ g.1^-1*g.2^-3*g.1^-1*g.2^-2*g.1^-1*g.2^-3*g.1^-1*g.2^-2*g.1^-1*\ g.2^-1*g.1^-1*g.2^-1, g.2^-2*g.1^-1*g.2^-1*g.1^-1 ] ) gap> Index( g, last ); 15 Is this not what you want? 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@math.rwth-aachen.de Mon Apr 26 14:01:30 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Mon, 26 Apr 93 14:01:30 +0200 Subject: Re: Subgroup(Parent(g),elts) David Sibley writes in his e-mail message of 1993/04/25: I just discovered an oddity in GAP and am trying to figure out why it is the way it is: Subgroup(g,elts) works only when g is a parent group. As far as I can see, this means that when I write programs, where I don't know whether g is going to be a parent group or not, I should actually use Subgroup(Parent(g),elts) instead of the above. But why does Subgroup not automatically use the parent of g, if that's what it needs, rather than making me explicitly say to use it? Or am I going to get into trouble using Subgroup(Parent(g),elts)? Each group is either a parent or a subgroup of a parent. The idea is that the parent may hold information that is needed for the subgroups. For example for finitely presented groups the parent holds the presentation. Thus subgroups must be subgroups of a parent, they cannot be subgroups of other subgroups (because those subgroups would not hold the information needed). Put another way, a parent is a structure in which computations are performed, and GAP allows only few operations between subgroups of different parents (basically only the set theoretic functions 'Intersection' etc.). That 'Subgroup' requires a parent as first argument is a reminder to this fact. It is true, 'Subgroup' could automatically take the parent of the first argument, but we found the current behaviour usefull. It helped us catch a few bugs, where we though a certain group was a parent, when in fact it was not. 'Subgroup( Parent(g), elts )' should not cause any problems. In fact, such a construct appears fairly often in the library. 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@math.rwth-aachen.de Wed Apr 28 11:05:37 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Wed, 28 Apr 93 11:05:37 +0200 Subject: new version of the Weyl-package Dear Mrs. and Mr. Forum, A new version of the Weyl-package is available on "samson.math.rwth-aachen.de" (and hopefully soon on "dehn.mth.pdx.edu" and "wuarchive.wustl.edu"): -r--r--r-- 1 ftp 39155 Apr 28 10:32 weyl.tar.Z -r--r--r-- 1 ftp 40641 Apr 28 10:32 weyl.zoo It features the following improvements: ----------------------------------------------------------------------------- Dear GAP-Forum, there are some small changes and one bug fix in the 'weyl' package. (However, every program written before should be 'upward compatible'.) You can see the changes in the following examples: # there are now non-cristallograhic (finite) Coxeter groups: gap> CartanMat("H",3); [ [ 2, E(5)^2+E(5)^3, 0 ], [ E(5)^2+E(5)^3, 2, -1 ], [ 0, -1, 2 ] ] gap> CartanMat("H",4); [ [ 2, E(5)^2+E(5)^3, 0, 0 ], [ E(5)^2+E(5)^3, 2, -1, 0 ], [ 0, -1, 2, -1 ], [ 0, 0, -1, 2 ] ] gap> CartanMat("I2",5); [ [ 2, E(5)^2+E(5)^3 ], [ E(5)^2+E(5)^3, 2 ] ] # there is now an 'operations' component in the Weyl group record so that # certain generic functions for domains will work for Weyl groups as well: gap> W:=Weyl(last); Weyl( [ [ 2, E(5)^2+E(5)^3 ], [ E(5)^2+E(5)^3, 2 ] ] ) gap> RecFields(W); [ "isDomain", "isWeylGroup", "cartan", "dim", "degree", "N", "roots", "matgens", "permgens", "parameter", "operations" ] gap> Size(W); 10 Some other changes improve the algorithms for computing Kazhdan-Lusztig polynomials and for calculations in Hecke algebras (which were rather slow before). E.g., on our HP computer, the command 'LeftCells( Weyl ( CartanMat( "F", 4 ) ) );' now takes roughly 5 hours cpu time. There was a bug in the programs for calculating in Hecke algebras, namely in the program which computed the inverse of a standard basis element. These changes were motivated by reports from other users. I should be very glad about any further such comments and suggestions for improvements. Aachen, 28.4.93, Meinolf Geck From aeb@win.tue.nl Wed Apr 28 17:52:07 1993 From: aeb@win.tue.nl "A. E. Brouwer" Date: Wed, 28 Apr 93 17:52:07 +0200 Subject: Interrupts etc. The past few days I have noticed several instances where interrupting GAP left me with a crippled version of GAP. One more instance happened a moment ago: I said gap> PrintRec(N); where N was some permutation group [B.t.w., PrintRec does not occur in the on-line help, only in the chapter About Gap] and this produced much more output than I liked. So, I gave ^C. Afterwards, N was partially mangled: gap> N; ~ gap> gap> PrintRec(N); ~gap> gap> Size(N); 729 gap> Print(N); ~gap> c in N; Error, Record: right operand must have '~.operations.in' Let me take this opportunity to ask a question. Do there exist facilities to regard an elementary abelian group as a vector space (and vice versa)? Do there exist facilities to go back and forth between a (permutation) group p^n:G with elem. ab. subgroup p^n and a matrix group G (with matrices of order n over GF(p))? Andries Brouwer From fceller@math.rwth-aachen.de Thu Apr 29 10:39:26 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Thu, 29 Apr 93 10:39:26 +0200 Subject: Re: Interrupts etc. A.E. Brouwer writes: The past few days I have noticed several instances where interrupting GAP left me with a crippled version of GAP. One more instance happened a moment ago: I said Yes, there is problem with interrupting GAP while printing. In order to avoid recursion while printing, GAP marks the objects which are already printed. If you interrupt GAP while it is printing, some objects are still marked, which causes this behavior. We will try to fix this in the next upgrade. best wishes Frank From sam@math.rwth-aachen.de Thu Apr 29 11:59:15 1993 From: sam@math.rwth-aachen.de "Thomas Breuer" Date: Thu, 29 Apr 93 11:59:15 +0200 Subject: vector spaces & modules Dear Mrs. and Mr. Forum, Andries Brouwer asks two questions concerning vector spaces, namely whether elementary abelian groups can be regarded as vector spaces and vice versa, and whether it is possible to describe the action of a group on an elementary abelian subgroup via a matrix representation. Here 'regard' and 'describe' apparently both mean that one has homomorphisms between the group and the vector space resp. between the group and the representation and its module. As stated recently in another message to the GAP forum, up to now there is no developed data structure representing vector spaces and modules in GAP, so the desired homomorphisms would not be of much help. But as soon as these domains and some functions dealing with them are available in GAP (hopefully in the next version), the questions of Andries Brouwer can be answered 'yes'. Thomas Breuer (sam@ernie.math.rwth-aachen.de) P.S.: What Andries Brouwer tells about the strange behaviour of '~' of course describes a bug, but I cannot say anything about when it will be fixed. From neubuese@math.rwth-aachen.de Thu Apr 29 17:20:24 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Thu, 29 Apr 93 17:20:24 +0200 Subject: bugs and trouble Dear GAP-forum, After some discussion, we want to introduce a new address gap-trouble@math.rwth-aachen.de The idea is the following. We have observed the discussions and reports in the GAP-forum as well as in the mail that some of us have got privately about GAP. These fall roughly into four categories: 1. Reports on what I like to call "real bugs", i.e. on instances where GAP produces a wrong answer to a problem, an answer that the user might even take for granted and thus might be led to wrong conclusions. The wrong abelian invariants, on which Daniel Ruberman reported recently, were such a case. (in which Martin fortunately could at least clarify that this was a rather exceptional malfunction). *We urge that each such case should by all means and as soon as *possible be reported in the GAP-forum in order to minimize the danger *that somebody is led to wrong conclusions. 2. Reports on annoying behaviour of GAP such as that of GAP after interrupting while printing that Andries Brouwer reported this morning. Such things are clearly annoying, they may cost the user's time, but at least (s)he cannot be led to wrong mathematical conclusions. The same applies to inefficiencies. We have no objection at all if these are sent to the GAP-forum, however more such reports seem to be sent directly to a private address in Aachen, most often to Martin Schoenert. We ask that such reports if not sent to the GAP-forum are rather sent to the above address "gap-trouble". Letters sent to that address will automatically be distributed to a small group of people who will jointly try to deal with the problems. This group will be started with Martin Schoenert (of course), Frank Celler, Thomas Breuer and myself, but whoever is willing to help us with the task to settle such deficiencies is invited to join the group (please just tell us to be put on the address list). Letters sent to "GAP-trouble" will get an individual reply to the sender and in addition we intend to give a report from time to time to the GAP-forum summarizing the troubles reported and our plans to deal with them, which may range from "yes will be fixed in the next patch" over "yes but has to wait for the next version" to "yes, but ...". We hope that by this scheme we cannot only distribute the workload a little bit more evenly, but also to minimize times of no reply when some of us are absent from Aachen. 3. Installation problems. The flood of them occurring in the GAP-forum after the release of GAP 3.2 even led to the proposal of a second forum. While we did not follow this suggestion, we think that if in the future such problems are also sent to "gap-trouble" and we report only on important and more often asked questions in the GAP-forum, we achieve some better organisation in this respect, too. 4. Questions "How can I do in GAP ...? " or "Can I do..?" These we would like to see further in the GAP-forum and we hope that often, as in the past, helpful answers will come from members of the forum outside of Aachen. The address "gap-trouble" will be operational from Friday, April 30. We hope that it will be a useful innovation and ask you to use it. Joachim Neubueser From scherrc@rosevc.rose-hulman.edu Thu Apr 29 18:32:44 1993 From: scherrc@rosevc.rose-hulman.edu "Chad Scherrer" Date: Thu, 29 Apr 93 18:32:44 +0200 Subject: Finding subgroups in GAP Is there a way in GAP to find all the subgroups of a given group, and if so, what about finding all normal subgroups of a given group? I realize these aren't of too great concern in doing most research, but I'm originally a Cayley user, and am in the habit of looping tests over the set of subgroups or the set of normal subgroups of a group. I'm currently in the process of switching over to using GAP, and have found equivalent commands for most of the things I could do in Cayley, but have had trouble finding any mention in the GAP documentation of how to find subgroups. Is there a way to do this in GAP? Sincerely, Chad Scherrer scherrc@rosevc.rose-hulman.edu From martin@math.rwth-aachen.de Thu Apr 29 18:55:12 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Thu, 29 Apr 93 18:55:12 +0200 Subject: Re: Finding subgroups in GAP Chad Scherrer writes in his e-mail messages of 1993/04/29 Is there a way in GAP to find all the subgroups of a given group, and if so, what about finding all normal subgroups of a given group? The function 'ConjugacyClassesSubgroups' will return the conjugacy classes of subgroups of a given group (whose largest perfect subgroup must have size <= 10000). With List( ConjugacyClassesSubgroups(G), Representative ); you get a list of representatives of the conjugacy classes, i.e., one subgroups from each conjugacy class. With Concatenation( List( ConjugacyClassesSubgroups(G), Elements ) ); you get all the subgroups. Note that 'ConjugacyClassesSubgroups' is somewhat slow for large solvable groups. I have rewritten this function so that it is now faster. This new implementation will be made available in the third upgrade (sorry I don't know when we will release this upgrade). The function 'NormalSubgroups' will return a list of normal subgroups of a given 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 l.h.soicher@qmw.ac.uk Thu Apr 29 19:32:00 1993 From: l.h.soicher@qmw.ac.uk "Leonard Soicher" Date: Thu, 29 Apr 93 19:32:00 +0200 Subject: GRAPE There is a bug in GRAPE, such that if you interrupt the CompleteSubgraphs function and quit the break loop, you may find the names field changed of the graph you input to this function. This has already been fixed in the QMW version of GRAPE, and will be fixed in the next public release of GRAPE. From hulpke@abacus.concordia.ca Fri Apr 30 09:48:39 1993 From: hulpke@abacus.concordia.ca "Alexander Hulpke" Date: Fri, 30 Apr 93 09:48:39 +0200 Subject: Re: Finding subgroups in GAP In his message, Chad Scherrer asked: > Is there a way in GAP to find all the subgroups of a given group, and if so, > what about finding all normal subgroups of a given group? GAP provides routines for both tasks. Subgroups are computed using the 'Lattice' command, which computes the whole lattice of subgroups (and stores conjugated subgroups is a somehow shortened form). In case you really want to have a list of all subgroups for looping over them, you might use l:=Lattice(g); # supposing g is your group s:=Flat(List(l.classes,Elements));; Then the variable 's' will contain a list of all subgroups. If you replace 'Elements' by 'Representative', you will obtain a list of representatives of each conjugacy class of subgroups. For computing all normal subgroups, GAP provides the command 'NormalSubgroups'. Yours, Alexander Hulpke From fceller@math.rwth-aachen.de Fri Apr 30 12:20:40 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Fri, 30 Apr 93 12:20:40 +0200 Subject: BUG: polynomials over the rationals Dear Mrs. and Mr. Forum, there is a bug in the 'Gcd' and 'mod' routines for polynomials over the rationals in GAP 3.2 Patchlevel 2. As far as I can see the routines will not give wrong result, but you *might* get a weird error message using 'mod' or an infinite loop in 'Gcd'. This will be fixed in the next patch kit. best wishes Frank From fceller@math.rwth-aachen.de Thu May 6 13:52:24 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Thu, 6 May 93 13:52:24 +0200 Subject: BUG: problems on HP9000 Dear Mrs. and Mr. Forum, there is a problem with GAP running on HP9000, which was discussed in "gap-trouble". I will give a brief summary of this discussion. If you start GAP with output redirection on HP9000 you *might* get an error message, saying "gap: panic 'SyGetmem' detected corrupted heap!". This error message is caused by a malloc from inside the C-library, we will include a work around for this in the next patch level. best wishes Frank From kaym@math.wayne.edu Sat May 8 18:15:55 1993 From: kaym@math.wayne.edu "Kay Magaard" Date: Sat, 8 May 93 18:15:55 +0200 Subject: PermChars Using the 3.1 version of GAP I noticed the following: On the one hand I get: gap> A:=CharTable("Symmetric",6);; gap> PermChars(A,6); [ ] gap> PermChars(A); Error, Variable: 'mino' must have a value at for in [ maxu .. mino ] ... in suche( 2 ) called from Permut( tbl, arec ) called from PermChars( A ) called from main loop brk> quit; On the other hand I get: gap> A:=CharTable("S6");; gap> PermChars(A,6); [ [ 6, 2, 0, 3, 0, 1, 0, 4, 2, 0, 1 ], [ 6, 2, 3, 0, 0, 1, 4, 0, 2, 1, 0 ] ] gap> Does a generic character table need to be reordered before asking for permutaion characters? If so how? From jcbhrb@cerf.net Mon May 10 01:33:23 1993 From: jcbhrb@cerf.net "Jacob Hirbawi" Date: Mon, 10 May 93 01:33:23 +0200 Subject: Calling a subroutine with a "list" instead of a "sequence" gap-forum@samson.math.rwth-aachen.de I hate bothering the forum with something this trivial, but I can't find anything in the manual that describes how to do the following: convert a "list" into a "sequence" -- (I am using the terminology of Mathematica where Sequence@@{1,2,3} returns 1,2,3 ). For example I would like to call "Group" not with r arguments each consisisting of a permeutation; but with a single argument consisting of a set of r permutations. gap> Group( (1,2),(3,4),(5,6) ); Group( (1,2), (3,4), (5,6) ) Obviously this doesn't work : gap> Group( [(1,2),(3,4),(5,6)] ); Error, operations: power of list and integer is not defined at id := arg[1] ^ 0 ... in Group( [ (1,2), (3,4), (5,6) ] ) called from main loop Thanks. Jacob Hirbawi JcbHrb@CERF.net PS. I tried mailing this to gap-trouble@samson.math.rwth-aachen.de and trouble@samson.math.rwth-aachen.de but it bounced back. I must be mis-remembering the name of the second forum; could someone remind me of it please. From fceller@math.rwth-aachen.de Mon May 10 09:23:17 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Mon, 10 May 93 09:23:17 +0200 Subject: Re: Calling a subroutine with a "list" instead of a "sequence" Jacob Hirbawi writes: gap> Group( [(1,2),(3,4),(5,6)] ); Error, operations: power of list and integer is not defined at id := arg[1] ^ 0 ... in Group( [ (1,2), (3,4), (5,6) ] ) called from main loop It is the second possibility listed in the manual that you want: 'Group( , )' 'Group' returns a new parent group G generated by group elements g_1, ..., g_n of . must be the identity of this group. The is needed because one might want to generate the trivial group, in which case the 'Group' function needs a hint what kind of group is to be constructed. In order to keep the calling convention uniform one cannot omit the even if the is not empty. gap> l := [ (1,2,3), (2,3,4) ]; [ (1,2,3), (2,3,4) ] gap> Group( l, () ); Group( (1,2,3), (2,3,4) ) He continues: I tried mailing this to gap-trouble@samson.math.rwth-aachen.de and trouble@samson.math.rwth-aachen.de but it bounced back. I must be mis-remembering the name of the second forum; could someone remind me of it please. The correct address is "gap-trouble@math.rwth-aachen.de" without the "samson". However, IMHO, this message belongs to "gap-forum" not to "gap-trouble", which should be used for technical problems concerning installation. best wishes Frank From pfeiffer@dmi.ens.fr Mon May 10 15:34:22 1993 From: pfeiffer@dmi.ens.fr "Goetz Pfeiffer" Date: Mon, 10 May 93 15:34:22 +0200 Subject: Re: PermChars In his message of 8 May 93 Kay Magaard described some difficulties with the computation of permutation characters for the symmetric group $S_6$ and asks: > Does a generic character table need to be reordered before > asking for permutaion characters? Sometimes, yes. 'PermChars' expects the 1-character to be the first one in the list 'irreducibles'. This is not the case for tables constructed by the generic table of symmetric groups. These tables are constructed in such a way that the labelling of the characters coincides with the labelling of the conjugacy classes. And the partition $[1^n]$ which labels the identity is the label for the sign character, not for the trivial one. (I will use the smaller table of the group $S_4$ as an example.) gap> s4:= CharTable("Symmetric", 4);; gap> DisplayCharTable(s4); S4 2 3 2 3 . 2 3 1 . . 1 . 1a 2a 2b 3a 4a 2P 1a 1a 1a 3a 2b 3P 1a 2a 2b 1a 4a X.1 1 -1 1 1 -1 X.2 3 -1 -1 . 1 X.3 2 . 2 -1 . X.4 3 1 -1 . -1 X.5 1 1 1 1 1 gap> s4.classparam; [ [ 1, [ 1, 1, 1, 1 ] ], [ 1, [ 2, 1, 1 ] ], [ 1, [ 2, 2 ] ], [ 1, [ 3, 1 ] ], [ 1, [ 4 ] ] ] gap> s4.irredinfo; [ rec( charparam := [ 1, [ 1, 1, 1, 1 ] ] ), rec( charparam := [ 1, [ 2, 1, 1 ] ] ), rec( charparam := [ 1, [ 2, 2 ] ] ), rec( charparam := [ 1, [ 3, 1 ] ] ), rec( charparam := [ 1, [ 4 ] ] ) ] After exchanging the first and the last character in the table 's4' by the function 'SortCharactersCharTable' the function 'PermChars' will do its job. gap> SortCharactersCharTable(s4, (1,5)); (1,5) gap> PermChars(s4, 4); [ [ 4, 0, 4, 1, 0 ], [ 4, 2, 0, 1, 0 ] ] There will be a more precise error message, if the 1-character is not in the expected position, in the next version. Goetz Pfeiffer. From pfeiffer@dmi.ens.fr Mon May 10 15:53:57 1993 From: pfeiffer@dmi.ens.fr "Goetz Pfeiffer" Date: Mon, 10 May 93 15:53:57 +0200 Subject: BUG in 'SortCharactersCharTable'. Dear Gap-Forum. I noticed a little bug in the function 'SortCharactersCharTable'. This function, if called in the form 'SortCharactersCharTable( )' with a character table as its only argument, is supposed to sort the characters in '.irreducibles' and then to apply the same permutation to the list '.irredinfo'. This doesn't work right if the 1-character is not the first one in the list 'irreducibles' and the table contains more than one character of degree one! gap> c2:= CharTable("Symmetric", 2);; gap> DisplayCharTable(c2); S2 2 1 1 1a 2a 2P 1a 1a X.1 1 -1 X.2 1 1 gap> c2.irredinfo; [ rec( charparam := [ 1, [ 1, 1 ] ] ), rec( charparam := [ 1, [ 2 ] ] ) ] gap> SortCharactersCharTable(c2); (1,2) gap> DisplayCharTable(c2); S2 2 1 1 1a 2a 2P 1a 1a X.1 1 1 X.2 1 -1 gap> c2.irredinfo; [ rec( charparam := [ 1, [ 1, 1 ] ] ), rec( charparam := [ 1, [ 1, 1 ] ] ) ] This will be fixed in the next upgrade. (The form 'SortCharactersCharTable( , )' with an explicit permutation as second argument, as suggested in the answer to Kay Magaard's letter, works.) Goetz Pfeiffer. From hulpke@abacus.concordia.ca Mon May 10 18:23:00 1993 From: hulpke@abacus.concordia.ca "Alexander Hulpke" Date: Mon, 10 May 93 18:23:00 +0200 Subject: Coefficients bug Dear Forum, Obviously, there is an error in the Coefficients routine for finite fields, as this example shows: gap> V:=VectorSpace([ Z(5)^0, Z(5^2)^2 ],GF(5)); VectorSpace( [ Z(5)^0, Z(5^2)^2 ], GF(5) ) gap> b:=Base(V); [ Z(5)^0, Z(5^2)^2 ] gap> c:=Coefficients(V,Z(5)^3); [ Z(5)^2, 0*Z(5) ] gap> c[1]*b[1]+c[2]*b[2]; Z(5)^2 However FiniteFieldOps.Coefficients (which I could not find in the manual) seems to work as expected and can be used to replace the faulty routine. Alexander Hulpke From sam@math.rwth-aachen.de Tue May 11 17:48:45 1993 From: sam@math.rwth-aachen.de "Thomas Breuer" Date: Tue, 11 May 93 17:48:45 +0200 Subject: Re: PermChars Dear Mrs. and Mr. Forum, Kay Magaard writes > Using the 3.1 version of GAP I noticed the following: > > On the one hand I get: > > gap> A:=CharTable("Symmetric",6);; > gap> PermChars(A,6); > [ ] > gap> PermChars(A); > Error, Variable: 'mino' must have a value at > for in [ maxu .. mino ] ... in > suche( 2 ) called from > Permut( tbl, arec ) called from > PermChars( A ) called from > main loop > brk> quit; > > On the other hand I get: > > gap> A:=CharTable("S6");; > gap> PermChars(A,6); > [ [ 6, 2, 0, 3, 0, 1, 0, 4, 2, 0, 1 ], > [ 6, 2, 3, 0, 0, 1, 4, 0, 2, 1, 0 ] ] > gap> > > > Does a generic character table need to be reordered before > asking for permutaion characters? > If so how? As Kay suspected and Goetz Pfeiffer told in his message to the forum, the reason for the error message and the incorrect answer in the case of the generic table is that the trivial character is not the first one in the list of irreducibles. Of course this is a bug (in fact there are two bugs, since 'PermChars' calls different algorithms for the calculation of all permutation character candidates or of all of a prescribed degree), since according to the manual (section 'Conventions'), no program shall expect the trivial character to be the first one. These bugs will be fixed in the next upgrade. In the current version of GAP, the user should move the trivial character to the first position when using 'PermChars', as proposed by Goetz. Kind regards Thomas Breuer (sam@ernie.math.rwth-aachen.de) From munemasa@math.sci.kyushu-u.ac.jp Wed May 12 11:08:49 1993 From: munemasa@math.sci.kyushu-u.ac.jp "Akihiro Munemasa" Date: Wed, 12 May 93 11:08:49 +0200 Subject: CharTable of grp of order 27 Dear Gap-Forum. I noticed a strange behavior in the function 'CharTable'. gap> g27:=AllThreeGroups(Size,27,IsAbelian,false); [ Group( a1, a2, a3 ), Group( a1, a2, a3 ) ] gap> G:=g27[1];; G.name:="G";; gap> t1:=CharTable(G);; Error, List Element: [1] must have a value at r := RootInt( Int( (D.deg - (D.num - anz) * D.degreePool[1][1] ^ 2) / anz ) ) ... in DegreeCandidates( D, d * mult ) called from SplitTwoSpace( D, raum ) called from CombinatoricSplit( D ) called from DixonSplit( D ) called from arg[1].operations.CharTable( arg[1] ) called from .. brk> GAP successfully computed the character table of all solvable nonabelian groups of order at most 100, except those of order 27. Akihiro Munemasa From hulpke@abacus.concordia.ca Wed May 12 16:28:17 1993 From: hulpke@abacus.concordia.ca "Alexander Hulpke" Date: Wed, 12 May 93 16:28:17 +0200 Subject: Re: CharTable of grp of order 27 Dear GAP-Forum, Akihiro Munemasa noticed a bug (politely denoted by him only as 'strange behaviour') in the 'CharTable' routine. It will arise, if there is no 'freedom' for the degrees of the non linear characters, i.e. if the character degrees are determined exactly by the number of classes and the number of linear characters. In this case, due to a forgotten '=', the largest character degrees are accidently thrown away, leading to problems. Fixing this bug fortunately is very easy (though I hope, this fix will also be included in the next patch): In the library file grpctbl.g change line 272 (which also is identified uniquely by its contents) from D.degreePool:=Filtered(D.degreePool,i->i[1]>1 and i[1]i[1]>1 and i[1]<=z/2); > GAP successfully computed the character table of all solvable > nonabelian groups of order at most 100, except those of order 27. With this fix, GAP will compute the character tables of all these groups (and also the non solvable ones). Side remark: 27 is a prime power. For groups of prime power order, CharTablePGroup normally works somehow faster than CharTable. As we were planning to use CharTablePGroup in these cases instead of the standard Dixon/Schneider algorithm, I never checked the two nonabelian groups of size 27. I better had. Please excuse this stupid bug. Yours Alexander Hulpke From tpd@aberystwyth.ac.uk Thu May 13 12:36:57 1993 From: tpd@aberystwyth.ac.uk "T. P. McDonough" Date: Thu, 13 May 93 12:36:57 +0200 Subject: A CharTable Problem. The following is a brief report on some difficulties encountered in the use of the CharTable function to get character tables of Weyl groups of type D. A problem seems to occur for even rank. An additional curiosity is that a character table is produced for W(D3) indicating a group of order 24 whose identity has a centralizer of order 48. Tom McDonough ========================================================================= Extracts from various GAP sessions, illustrating some problems in attempting to generate the character tables for Weyl groups of type D. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - gap> CharTable("WeylD",4); Error, Range: must be an integer at for in [ i - k + 1 .. i - 1 ] ... in CharValueSymmetric( n, BetaSet( alpha ), pi ) called from CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 ) called from gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] ) called from fun( i ) called from List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from .. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - gap> CharTable("WeylD",6); Error, Range: must be an integer at for in [ i - k + 1 .. i - 1 ] ... in CharValueSymmetric( n, BetaSet( alpha ), pi ) called from CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 ) called from gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] ) called from fun( i ) called from List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from .. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - gap> CharTable("WeylD",8); Error, Range: must be an integer at for in [ i - k + 1 .. i - 1 ] ... in CharValueSymmetric( n, BetaSet( alpha ), pi ) called from CharTableSymmetric.irreducibles[1][1]( n / 2, alpha[1], pi[1] / 2 ) called from gtab.irreducibles[genchar[i]][genclass[j]]( q, charparam[i], classparam[j] ) called from fun( i ) called from List( [ 1 .. Length( classparam ) ], function ( j ) ... end ) called from .. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - These commands were successful, but I haven't checked whether the results are correct. gap> CharTable("WeylD",5); gap> CharTable("WeylD",7); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Finally, an interesting record. gap> CharTable("WeylD",3); rec( name := "W(D3)", order := 24, centralizers := [ 48, 8, 8, 4, 6 ], orders := [ 1, 2, 2, 4, 3 ], powermap := [ , [ 1, 1, 1, 2, 5 ], [ 1, 2, 3, 4, 1 ] ], irreducibles := [ [ 3, -1, -1, 1, 0 ], [ 1, 1, -1, -1, 1 ], [ 3, -1, 1, -1, 0 ], [ 2, 2, 0, 0, -1 ], [ 1, 1, 1, 1, 1 ] ], classparam := [ [ 1, [ [ 1, 1, 1 ], [ ] ] ], [ 1, [ [ 1 ], [ 1, 1 ] ] ], [ 1, [ [ 2, 1 ], [ ] ] ], [ 1, [ [ ], [ 2, 1 ] ] ], [ 1, [ [ 3 ], [ ] ] ] ], irredinfo := [ rec( charparam := [ 1, [ [ 1 ], [ 1, 1 ] ] ] ), rec( charparam := [ 1, [ [ ], [ 1, 1, 1 ] ] ] ), rec( charparam := [ 1, [ [ 1 ], [ 2 ] ] ] ), rec( charparam := [ 1, [ [ ], [ 2, 1 ] ] ] ), rec( charparam := [ 1, [ [ ], [ 3 ] ] ] ) ], text := "computed using generic character table for Weyl groups of type D"\ , classes := [ 1, 6, 6, 12, 8 ], operations := CharTableOps ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From pfeiffer@dmi.ens.fr Thu May 13 12:00:53 1993 From: pfeiffer@dmi.ens.fr "Goetz Pfeiffer" Date: Thu, 13 May 93 12:00:53 MET Subject: Re: A CharTable Problem. In his message of 13 May 1993 Tom McDonough desrcibes > some difficulties encountered in the > use of the CharTable function to get character tables of Weyl groups > of type D. These problems came into the package with the new concept for strings in GAP. The classes and characters of Weyl groups of type D are labelled by pairs of partitions. For even rank certain labels occur twice. They are distinguished by a "+" or "-" sign in the place of the second partition. The functions for the constuction of the character table try to recognise these signed labels by 'IsString(pi[2])'. But the second partition may also be empty, represented by the empty list. And due to the new string concept, the empty list is now recognised as a string, too. This leads to the problems encountered by Tom McDonough. This will be fixed with the next upgrade. Then the signs in the labels will no longer be strings but single characters: '+' and '-'. This means 'CharTable("WeylD", )' and 'CharTable("Alternating", )' will then produce slightly different results. I hope this causes no problems. In the meantime a possible workaround is to replace the function 'IsString' by one that ignores the empty list: gap> IsStr:= IsString; function (...) internal; end gap> IsString:= function(obj) > return obj <> [] and IsStr(obj); end; function ( obj ) ... end WARNING: This might have side-effects in places where the empty string is relevant. But now it is possible to compute the tables and centralizers are no longer bigger than the whole group. gap> CharTable("WeylD", 3); rec( name := "W(D3)", order := 24, centralizers := [ 24, 8, 4, 4, 3 ], orders := [ 1, 2, 2, 4, 3 ], powermap := [ , [ 1, 1, 1, 2, 5 ], [ 1, 2, 3, 4, 1 ] ], irreducibles := [ [ 3, -1, -1, 1, 0 ], [ 1, 1, -1, -1, 1 ], [ 3, -1, 1, -1, 0 ], [ 2, 2, 0, 0, -1 ], [ 1, 1, 1, 1, 1 ] ], classparam := [ [ 1, [ [ 1, 1, 1 ], [ ] ] ], [ 1, [ [ 1 ], [ 1, 1 ] ] ], ... Goetz Pfeiffer. PS: a detailed description of the implementation of the character tables of Weyl groups and related groups will soon be available via anonymous ftp from 'samson.math.rwth-aachen.de'. From dfh@maths.warwick.ac.uk Wed May 19 16:44:44 1993 From: dfh@maths.warwick.ac.uk "Derek Holt" Date: Wed, 19 May 93 16:44:44 +0200 Subject: Query about finite fields Dear GAP Forum, I have a query about the construction of finite fields using the form GaloisField(p,pol), where pol is a polynomial. The first remark is that this function does not in fact expect a GAP polynomial at all, but a list of coefficients. That is not a serious problem, however. My main problem is how to refer to the field elements once the field is constructed. I want to refer to them as polynomials over the ground field in the indeterminate w, where 'pol' is the minimal polynomial of w that I have specified. But how do I refer to w? If w is a primitive root, then it apparently is given by F.root. e.g. gap> F:=GF(2,[Z(2)^0, 0*Z(2), Z(2)^0,Z(2)^0 ]); GF(2^3) gap> F.root; Z(2^3)^3 gap> MinPol(F.root); [ Z(2)^0, 0*Z(2), Z(2)^0, Z(2)^0 ] gap> but, in general, w may not be a primitive root and, if not, then F.root does not appear to get itself defined at all. e.g. gap> F:=GF(2,[ Z(2)^0, Z(2)^0, Z(2)^0, Z(2)^0, Z(2)^0 ]); GF(2^4) gap> F.root; Error, Record: element 'root' must have an assigned value gap> This is serious, because a lot of the GAP code that I have written for finite fields uses the .root component. Is there any way that I can define F.root in such a case without causing problems? Or do I have to make sure that I only call the function for primitive elements? Derek Holt. From stiller@blaze.cs.jhu.edu Thu May 20 22:33:57 1993 From: stiller@blaze.cs.jhu.edu "Lewis Stiller" date: Thu, 20 May 93 22:33:57 +0200 Subject: Cayley graphs Does anyone have software for looking the Cayley graph or Cayley color graph (also called the group graph) of a group in GAP; and the related group action graph? (Given a group G generated by some elements T and acting on a set X, the group action graph (G,T,X) has as nodes X and an edge optionally colored t from each x\in X to each t x\in x for each t\in T. ) Please reply via email. Lewis Stiller Department of Computer Science The Johns Hopkins University 3400 North Charles St. Baltimore, MD 21218-2194 stiller@cs.jhu.edu From martin@math.rwth-aachen.de Thu May 20 22:44:24 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Thu, 20 May 93 22:44:24 +0200 Subject: Re: Coefficients bug Alexander Hulpke writes in his e-mail message of 1993/05/10: Obviously, there is an error in the Coefficients routine for finite fields, as this example shows: This is correct. In fact I would bet that there are more things in the vector space package that are faulty. Unfortunately I don't think that this is very simple to fix. We plan to rewrite the whole vector space package (and add lots of related stuff, like modules). We can not make any promises when this will be available. Alexander continues: However FiniteFieldOps.Coefficients (which I could not find in the manual) seems to work as expected and can be used to replace the faulty routine. Again this is correct (at least I hope that 'FiniteFieldOps.Coefficients' is correct, since I wrote it ;-). Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany From hulpke@abacus.concordia.ca Fri May 21 18:00:24 1993 From: hulpke@abacus.concordia.ca "Alexander Hulpke" Date: Fri, 21 May 93 18:00:24 +0200 Subject: Re: Query about finite fields Dear GAP Forum, In his letter, Derek Holt raised some questions concerning finite fields and extensions. As I had to deal with similar problems recently, when writing a routine to factor a polynomial over an algebraic extension, I probably can give some advices on this them. As I'm not the author of the finite fields routines, I cannot comment, on modifying the 'root' component (however, I assume, that one might create quite weird errors by setting this field to an element, which is *not* a primitive root), myself I just would not dare to do such things. > This is serious, because a lot of the GAP code that I have written for finite > fields uses the .root component. Is there any way that I can define F.root > in such a case without causing problems? Or do I have to make sure that I > only call the function for primitive elements? The question is: What will your code need the '.root' component for ? Will it just need a primitive element of the extension, or does it rely on the 'primitive root' property? In the first case, I just would refer to the component '.generators[2]' instead, which contains a root of the generating polynomial, i.e. a primitive element. Otherwise of course, you will have to select special polynomials (as the Conway polynomials). > My main problem is how to refer to the field elements once the field is > constructed. I want to refer to them as polynomials over the ground > field in the indeterminate w, where 'pol' is the minimal polynomial of w > that I have specified. But how do I refer to w? By F.operations.Coefficients (Do *not* use Coefficients, which contains a bug) you can get the coefficients of a field element with respect to the selected base. As GF selects a base to be powers ([0..d-1]) of a primitive element, you will get exactly what you wanted, if you regard the obtained coefficient list again as a polynomial. Maybe this is of help. Yours Alexander Hulpke From l.h.soicher@qmw.ac.uk Sat May 22 17:47:22 1993 From: l.h.soicher@qmw.ac.uk "Leonard Soicher" Date: Sat, 22 May 93 17:47:22 +0200 Subject: Re: Cayley graphs Lewis Stiller asks about software to look at Cayley graphs and group action graphs. What he needs is the GRAPE package for computing with graphs and groups, which runs under the GAP system. In fact, GRAPE 2.1 is about to be released as a GAP share package. For now, here is a sample GRAPE computation of a CAYLEY graph for the symmetric group S4, and some calls to GRAPE functions showing that this graph has diameter 4, girth 6, and an automorphism group of order 144. gap> G:=SymmetricGroup(4); Group( (1,4), (2,4), (3,4) ) gap> T:=G.generators; [ (1,4), (2,4), (3,4) ] gap> Cayley:=Graph(G,Elements(G),OnRight,function(x,y) return y/x in T; end); rec( isGraph := true, order := 24, group := Group( ( 1, 2)( 3, 7)( 4, 9)( 5,11)( 6,13)( 8,16)(10,19)(12,21) (14,24)(15,23)(17,22)(18,20), ( 1, 3)( 2, 5)( 4,10)( 6,14)( 7,11)( 8,17) ( 9,18)(12,22)(13,23)(15,24)(16,21)(19,20), ( 1, 4)( 2, 6)( 3, 8)( 5,12) ( 7,15)( 9,13)(10,17)(11,20)(14,22)(16,23)(18,21)(19,24) ), schreierVector := [ -1, 1, 2, 3, 2, 3, 1, 3, 1, 2, 1, 3, 1, 2, 3, 1, 2, 2, 1, 3, 1, 2, 2, 1 ], adjacencies := [ [ 2, 3, 4 ] ], representatives := [ 1 ], names := [ (), (1,4), (2,4), (3,4), (1,2,4), (1,3,4), (1,4,2), (2,3,4), (1,4,3), (2,4,3), (1,2), (1,2,3,4), (1,3), (1,3,2,4), (1,3,4,2), (1,4,2,3), (2,3), (1,2,4,3), (1,4,3,2), (1,2)(3,4), (1,2,3), (1,4)(2,3), (1,3)(2,4), (1,3,2) ] ) gap> Diameter(Cayley); 4 gap> Girth(Cayley); 6 gap> Size(AutGroupGraph(Cayley)); 144 gap> quit; L.H.Soicher@qmw.ac.uk From neubuese@math.rwth-aachen.de Tue Jun 1 18:35:49 1993 From: neubuese@math.rwth-aachen.de "Joachim Neubueser" Date: Tue, 1 Jun 93 18:35:49 +0200 Subject: Mr. Leonard's letter In a letter of April 19 to the GAP-forum Frank Leonard wrote >"I have been attempting some constructions of finite groups in GAP as >defined by a presentation in abstract generators/relators. The >problem consists of applying a certain algorithm to construct a group >which I then attempt to identify. I also have access to the C.A. >package CAYLEY and have re-written the algorithm for CAYLEY. I have >found CAYLEY vastly superior (time wise) to GAP for this problem. I >assume that the fact that GAP programs/functions are interpreted would >be significant in explaining the discrepancies but I am curious if >there are any other factors which might be significant. Can you tell >me if there are any plans at present to write a compiler for GAP?" In my reply I have made no attempt to hide my disappointment about such unspecified but nevertheless very critical comment. On this I have obtained a letter from Mr. Leonard which starts: >"The following is a personal message and is not intended for >submission to the GAP-forum." I have to respect this. However I do not think that I break this confidentiality if I report that after saying later on in his letter: >"I have been deliberately vague about the details of my constructions >in my submission as the material on which I have based my GAP program >forms the basis of a paper..." Mr. Leonard reports that he has used the GAP-function Size(g) on a two-generator, two-relator presentation of the trivial group which he then gives, thus allowing us to analyze the case. He states that it took him approximately 20 sec using the GAP-command Size(g) and less than a second in Cayley to find that the presentation does in fact describe the trivial group. We have repeated the calculations and found the statement correct, on a DECstation Size(g) took 15 sec, Cayley took 0.5 sec. I only wished, Mr. Leonhard had made this explicit statement in his first letter, because this gives me a chance to explain the reasons and talk about consequences of the observation. Both programs use Todd-Coxeter coset enumeration methods. The one in Cayley is implemented by George Havas in C, the one in GAP is written by Martin Schoenert in the GAP-language with some time-critical parts in C in the GAP kernel. There is a standalone version of Martin Schoenert's program written by him totally in C and so the first step is a comparison of this and the GAP function. The respective time for Martin Schoenert's C program is 4.7 sec, as stated above the time for the GAP function 15 sec. This factor is rather typical, factors of 3 - 4 have also been observed with other presentations. This factor is due to two reasons, the fact that GAP is interpreted but also to the overhead time needed for the dynamic storage allocation using indirections. We do not know exactly which proportion of the factor is due to which of the reasons but it is clear that even compilation would not remove the second reason. It is also clear that both reasons hit in particular with programs in which rather small data has to be accessed many times and Todd-Coxeter methods are one of the worst cases for this phenomenon. There remains quite a substantial factor to be explained. The first to note is that there are several "strategies" for the Todd-Coxeter method, which can have an enormous, unfortunately not completely a priori predictable influence on the efficiency. There are some papers investigating experimentally these various strategies, in particular J.J. Cannon, L.A. Dimino, G. Havas, J.M. Watson : Implementation and Analysis of the Todd-Coxeter Algorithm. Math. of Computation, 27, (1973), 463 - 490. G. Havas : Coset Enumeration Strategies. Proc. ISSAC 91. and George Havas is carrying out further investigations. Without going into details: There are two 'old' strategies, the so-called Felsch strategy and the so-called HLT strategy (after Haselgrove, Leech, and Trotter), of which 'in general' (such statements always have exceptions, and Mr. Leonard's example is one) the Felsch method tends to define fewer redundant coset numbers and hence to need less space while the HLT method tends to be faster. (Both have been improved by modifications, but this does not matter too much here.) Now the times observed by Mr. Leonard are for the default strategies in GAP and Cayley. The very short time in Cayley is obtained by a HLT strategy, but as George Havas, whom I want to thank for his help in investigating the case, has pointed out, also with a bit of luck: If he just cyclically permutes the relators, his program in CAYLEY takes 3 times longer because it defines 3 times more coset numbers before collapsing the coset table!! (maximal table size 69909 instead of 21860, 1.570 sec instead of 0.530sec, times on his machine which I believe is a SUN) The method used in GAP is basically a Felsch method, there is no GAP implementatiom of a HLT based method yet. Modifications of the method cause rather drastic changes in efficiency of a Felsch method, too, as in particular George Havas has investigated. E.g. using the relators also as subgroup generators in a Felsch strategy mode of George Havas' program reduces the maximal table size from 27532 (which is the same as in the GAP program) to 17012 and computing times from 2.29 sec to 1.40 sec. This is because in George's program subgroup generators are scanned a la HLT. Using in addition a 'Preferred Definition List', a strategy developped by George Havas, reduces the maximal table size further to 9542 and the computing time 0.84 sec. These figures make clear that the choice of the strategy is a delicate matter and that the comparison made originally used defaults that were particularly unlucky for the performance of GAP. What are the consequences for us? For very large enumerations the factor of 3 or 4 caused by indirection and interpretation is annoying. We will therefore gratefully accept the offer of George Havas to append his C-program, which at present probably represents the greatest experience with the above mentioned delicate decisions, as a share library to GAP. George will eventually provide us with the C source code for the purpose, but he wants to polish the code first, so we may first try to provide executables of his program for a few computers. Using such a share library of course has the drawback (which is the payment for some of its speed) that it is running on its own piece of storage that is not administered by the GAP storage management. Therefore we also intend to learn more from George's experience and also try to improve the TC written in the GAP-language, even if more or less intrinsicly we will loose that factor of 3 or 4 against a standalone C-program. This has become a long letter, allow me nevertheless to mention another case of an efficiency comparison. Both GAP 3.2 and CAYLEY have programs for the computatipon of the subgroup lattice, which we are allowed to compare even more since they have both been written in Aachen. The CAYLEY program was written by Volkmar Felsch, originally still in Fortran, then semiautomatically translated into C by John Cannon. Volkmar Felsch is still helping to maintain this program, the last such help was given only this Spring. The GAP program was written by Juergen Mnich. Of course, when he had written it, we made comparisons and were rather content with the results: For small groups the two performed roughly equal while for big permutation groups (big for this kind of program) such as the symmetric group S8 or the Mathieu group M12 the new program was faster by a factor over 10, which matters for these cases since absolute computing time is over one hour for the new program for these cases. This was at least partially due to the use of new functions for permutation groups. We were rather surprised to learn from Ralf Dentzer that the performance of the new program was not so satisfactory for medium size soluble groups with thousands of classes of conjugate subgroups e.g. certain groups of order 256 from Eamonn O'Brien's list for which the new program performed by about the same factor of 10 *slower* than the old one. Martin Schoenert has very briefly mentioned this fact in a reply to a question in the GAP-forum recently and also mentioned that he has written a still newer progam in GAP which seems to avoid these deficiencies for medium size soluble groups while keeping the good performance for the 'big' groups. This program will be put into GAP in the not too far future. I mention the second case after my report about the first in order to make the point that in cases such as the computation of the subgroup lattice of a 'big' permutation group the fact that GAP is interpreted and the storage management uses indirections does not play such an important role for the efficiency while on the other hand the simplicity of programming in GAP makes it much more feasable to try a mathematical variant of a method that can improve the efficiency. Last not least however I want to emphazise that we do appreciate clear and specific reports, such as given to us by Ralf Dentzer, about deficiencies in GAP, deficiencies which we shall then try to remove as much and as soon as our restricted manpower allows, and that the last thing we want to do is to sweep such problems under the carpet. Joachim Neubueser From hulpke@abacus.concordia.ca Wed Jun 9 17:33:46 1993 From: hulpke@abacus.concordia.ca "Alexander Hulpke" Date: Wed, 9 Jun 93 17:33:46 +0200 Subject: GAP on DEC alpha machines Dear Forum, The subject line sais most: Has anyone compiled (and run) GAP succesfully on a DEC alpha machine? I can compile it successfully, but the garbage collector will crash. Many thanks Alexander Hulpke From caranti@volterra.cineca.it Mon Jun 14 11:38:48 1993 From: caranti@volterra.cineca.it "A. Caranti" Date: Mon, 14 Jun 93 11:38:48 +0200 Subject: GAP on DEC alpha machines Dear Forum, Alexander Hulpke writes > The subject line says most: Has anyone compiled (and run) GAP > successfully on a DEC alpha machine? I can compile it successfully, but > the garbage collector will crash. This is just to report that I've had the same experience. I compiled GAP with the bsd option. But when it comes to running it, it does not work: long integer arithmetics gives nonsense, and any attempt of doing anything results in a crash ("Memory fault"). I might add that a colleague of mine has had similar problems with a C program of his: it compiles, but then crashes immediately. Andreas Caranti From dana@bimacs.cs.biu.ac.il Mon Jun 14 11:56:22 1993 From: dana@bimacs.cs.biu.ac.il "Dana-Picard Noah" Date: Mon, 14 Jun 93 11:56:22 +0200 Subject: installation Dear Forum, People here made for me the installation of GAP under UNIX. When I tried to run it, as soon as I call to some function I get the following message: the library file 'filename' must exist and be readable in ReadLib("filename") called from main loop What have we to do? Thanks a lot, Thierry Dana-Picard. From slinton@math.rwth-aachen.de Mon Jun 14 16:32:19 1993 From: slinton@math.rwth-aachen.de "Steve Linton" Date: Mon, 14 Jun 93 16:32:19 +0200 Subject: installation People here made for me the installation of GAP under UNIX. When I tried to run it, as soon as I call to some function I get the following message: the library file 'filename' must exist and be readable in ReadLib("filename") called from main loop What have we to do? You need to tell GAP where to find it's library files. If you haven't installed the library it can be obtained from whereever you got GAP in the file lib3r2.zoo or lib3r2.tar.Z. If you have installed it already then you should call GAP with the -l option to indicate where the library is. For example gap -l /usr/local/gap/lib An easy way to do this is to call gap by way of a shell script. Typically the shell script is called /usr/local/bin/gap, and is something like #!/bin/sh /usr/local/gap/src/gap -l /usr/local/gap/lib -h /usr/local/gap/doc $* The -h option specifies the location of the documentation files used to provide the on-line help. You will have to change the path-names to suit your system. Steve Linton From martin@math.rwth-aachen.de Mon Jun 14 16:48:01 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Mon, 14 Jun 93 16:48:01 +0200 Subject: Re: GAP on DEC alpha machines Alexander Hulpke writes in his e-mail message of 1993/06/09 The subject line sais most: Has anyone compiled (and run) GAP succesfully on a DEC alpha machine? I can compile it successfully, but the garbage collector will crash. GAP wont run on DEC Alpha machines. The problem is that the storage manager (Gasman) and the arbitrary integer package assume that the size of a pointer and and an unsigned long integer are 32 bit. On the Alpha machines however, they are 64 bit large. There is currently no fix for that. I have written a new storage manager that appears to work on the DEC Alpha machines. This storage manager will be in GAP 4.1. We cannot make any promises as to when this version will become available. There is another approach that might be possible. DEC offers a migration tool that can be used to migrate binaries from DECstations (with the MIPS R3000 processor) to binaries for the DEC Alpha machines (with the new Alpha processor). I dont know whether it would be possible to migrate the GAP kernel this way, and in any case such a migrated kernel would run slower than a kernel compiled on an Alpha. But it would be worth a try and would certainly be better than to wait for GAP 4.1. 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 smith@pell.anu.edu.au Thu Jun 17 09:03:06 1993 From: smith@pell.anu.edu.au "Michael Smith" Date: Thu, 17 Jun 93 09:03:06 +0200 Subject: GAP on Mac Hello N.(?), You said (quite some time ago) that as soon as GAP 3.2 was installed on your mainframe, that it would be ported to the Mac. Is this likely to happen soon? Thanks, Michael. ----------------------------/|-|--|-|--|------Michael-Smith------------------- smith@pell.anu.edu.au /_| |\ | | | Mathematics Research Section --------------------------/--|-|-\|-|_/|------Australian-National-University-- From martin@math.rwth-aachen.de Thu Jun 17 09:40:32 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Thu, 17 Jun 93 09:40:32 +0200 Subject: Stabilizer Chains I would like to change the format of stabilizer chains for permutation groups slightly. Because they are described in the manual this would violate our claim that we will remain compatible with what is described in the manual. The purpose of this message is to find out whether nobody is relying on the format of stabilizer chains so that I can change it for GAP 3.3, or whether I shall only make an intermediate change for GAP 3.3 and wait until GAP 3.4 with the full change. I want to make two changes, of which only the first would be visible. Currently the group itself is the top level stabilizer, e.g., the group record itself has the components '.orbit' and '.stabilizer'. I want to change this so that the group record contains only the component '.stabchain', and it is this record that contains the components '.orbit' and '.stabilizer' for the top level. The idea behind this is that all components in group record should be independent, so that a user might delete those whithout the possibility to create inconsistent group records (as would now happen if the user deleted only '.stabilizer'). This change is also needed for the second change. The second change would be to change the base change function so that it never changes stabilizer chains (destructively), but always creates new stabilizer chains. The idea behind this change is that quite a number of functions must copy entire stabilizer chains, because that would fail if the stabilizer chain was changed. For example 'Stabilizer' (of a single point or list of points), makes a base change, so that the new base starts with the points to be fixed, and then installs a *copy* of the remainder of the chain as chain of the stabilizer. This copying could be avoided if stabilizer chain would not be changed. At the same time I will also change 'MakeStabChain' so that it will not install the stabilizer chain into the group record, until it is complete. The reason is that quite a few users have complained that after interrupting a stabilizer chain computation, the group record was in an inconsistent state (which will cause incorrect answers for 'Size', 'Centralizer', etc.). 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 smith@pell.anu.edu.au Thu Jun 17 09:52:42 1993 From: smith@pell.anu.edu.au "Michael Smith" Date: Thu, 17 Jun 93 09:52:42 +0200 Subject: GAP on Mac Dear GAP-forum readers, My apologies. My last message was intended to be a message to N. S. Mendelsohn, not to the forum. I'll try to be more careful in future. Michael. From mendel@ccu.umanitoba.ca Thu Jun 17 17:55:28 1993 From: mendel@ccu.umanitoba.ca "N. S. Mendelsohn" Date: Thu, 17 Jun 93 17:55:28 +0200 Subject: GAP on MAC Harry Lakser tells me that GAP 3.2 for the Mac is almost ready. The original transfer was quite difficult, but now that he knows how to do it the problem has become more or less routine. The time delays are due to the fact that Lakser has a number of other priorities. N. S. Mendelsohn From schwartz@symcom.math.uiuc.edu Fri Jun 18 00:55:57 1993 From: schwartz@symcom.math.uiuc.edu "Gary K. Schwartz" Date: Fri, 18 Jun 93 00:55:57 +0200 Subject: Table Libraries I am having a problem creating libraries of character tables. I'm running GAP 3.2 on a 486 PC. It seems that in the last paragraph of section 46.6 of the manual, you say that the file which is printed by PrintToLib must be edited, but there's no example and I don't understand. Please give me an example starting with an arbitrary character table that you want to save, and please include all the steps from saving it, to notififying the library table, to reading it back. Thank you Gary Schwartz From sam@math.rwth-aachen.de Fri Jun 18 17:41:27 1993 From: sam@math.rwth-aachen.de "Thomas Breuer" Date: Fri, 18 Jun 93 17:41:27 +0200 Subject: table libraries Dear Mrs. and Mr. Forum, Gary Schwartz writes in his message of today: > I am having a problem creating libraries of character tables. I'm > running GAP 3.2 on a 486 PC. It seems that in the last paragraph of > section 46.6 of the manual, you say that the file which is printed by > PrintToLib must be edited, but there's no example and I don't > understand. Please give me an example starting with an arbitrary > character table that you want to save, and please include all the steps > from saving it, to notififying the library table, to reading it back. Here is an example. Just now I realized that it might be not very comfortable to include character tables in a private library. In the next version this will be a bit easier. Let's say we are interested in the table of the symmetric group S3 ... gap> CharTable( "S3" );; #E CharTableLibrary: no library table with name 'S3' .. but it is not in the library. So let's add it. gap> g:= SolvableGroup( 6, 2 ); S3 gap> t:= CharTable( g );; gap> t.name; "S3" gap> PrintToLib( "table", t ); The file 'table' in the current directory contains the table. We have to notify it, and want to allow access to it as 'mytable'. (This must be done for every GAP session, for example statements like this can be put into the '.gaprc' file.) NotifyCharTable( t.name, "table", [ "mytable" ] ); Now there are two problems. The first is that GAP does not know in which directories it shall search for the tables; therefore we add the pathname of the directory to 'TBLNAME'. gap> TBLNAME; "/usd/gap/3.3/tbl/" gap> Append( TBLNAME, ";/usd/sam/tbl/" ); The second problem (or a bug in GAP, perhaps) is that table files are expected to have an extension '.tbl', but our file has not yet. (This will be fixed in the next version of GAP.) gap> Exec( "mv table table.tbl" ); Now we are done. gap> new:= CharTable( "mytable" );; gap> DisplayCharTable( new ); S3 2 1 . 1 3 1 1 . 1a 3a 2a 2P 1a 3a 1a 3P 1a 1a 2a X.1 1 1 1 X.2 1 1 -1 X.3 2 -1 . Note that at the moment it might cause difficulties if the filename contains special characters, e.g. '.'; this will also be fixed in the next version of GAP. Kind regards Thomas Breuer (sam@ernie.math.rwth-aachen.de) From martin@math.rwth-aachen.de Mon Jun 21 09:58:42 1993 From: martin@math.rwth-aachen.de "Martin Schoenert" Date: Mon, 21 Jun 93 09:58:42 +0200 Subject: '.root' We have received some e-mail messages asking about what the component '.root' in a finite field record really is. The component '.root' is only present if the finite field was contructed as an extension with a primitive polynomial (i.e., one whose root is a generator of the multiplicative group), and in this case it is one of the roots of this polynomial. If the finite field was constructed with an irreducible but not primitive polynomial, the component '.root' is not present, but a root of this polynomial is still available. Namely the base of the new field as vector space over the ground field consists of the first powers of a root. Thus '.generators[1]' is a root of the polynomial. To clear up things a little bit we suggest the following name change '.root' -> '.primitiveRoot' and plan to add a new component '.primitiveElement'. And of course we are also going to add the above paragraphs to the manual. Any objections? 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 wright@bright.uoregon.edu Tue Jun 22 18:21:10 1993 From: wright@bright.uoregon.edu "Charley Wright" Date: Tue, 22 Jun 93 18:21:10 +0200 Subject: SubnormalSeriesPPermGroup Greetings from Oregon, where it still hasn't stopped raining. There is a minor problem with SubnormalSeriesPPermGroup. Here is an example: gap> C := Group((1,2,3,4));; C.name := "c4";; gap> gap> sns := SubnormalSeriesPPermGroup( C ); [ c4, Subgroup( c4, [ (1,3)(2,4) ] ), Subgroup( c4, [ ] ) ] gap> gap> sns[2].elements; [ () ] gap> gap> IsSubgroup(sns[2], sns[2]); false The wrong answer in IsSubgroup comes from the wrong value of sns[2].elements. The cause of the trouble seems to be a call to TrivialSubgroup in SubnormalizerSeriesPPermGroup. TrivialSubgroup introduces the element (), which then persists as the only element ever produced. It would be possible to revise SubnormalSeriesPPermGroup so as to maintain correct element lists of all the subgroups in the chains in generates, but it seems to make more sense simply not to generate any elements at all. The easy way to do that is to replace the line H := TrivialSubgroup(G); by H := Subgroup(G, []); in SubnormalSeriesPPermGroup. With this change, SubnormalSeriesPPermGroup and CentralCompositionSeriesPPermGroup produce chains of subgroups for which .element is not bound, and hence for which quotient factors can be computed as called for. The trivial subgroup strikes again! Charley wright@math.uoregon.edu From aszczepa@umpa.ens-lyon.fr Wed Jun 23 11:52:29 1993 From: aszczepa@umpa.ens-lyon.fr "A. Szczepanski" date: Wed, 23 Jun 93 11:52:29 METDST Subject: coxeter Dear gap-forum, Gerhard Hiss informed me that you can help me in the following problem: How find the torsion free subgroup of finite index in the Coxeter group ? I have several examples of Coxeter groups for which I want to find a torsion free subgroup of finite index.The simplest is: 4 4 infinity . -- . -- . -- . -- . -- . The Coxeter diagram ( linear) with 6 vertex and 5 edges. The first two edges have "balanced" number 4 and the last edge has number "infinity". Thank you in advance.Sincerely Yours.Andrzej Szczepanski. From wright@bright.uoregon.edu Wed Jun 23 20:44:33 1993 From: wright@bright.uoregon.edu "Charley Wright" Date: Wed, 23 Jun 93 20:44:33 +0200 Subject: CompositionSeriesSolvablePermGroup A postscript to my last note: CompositionSeriesSolvablePermGroup has the same difficulty that SubnormalSeriesPPermGroup has. The TrivialSubgroup in its else branch creates subnormal subgroups whose element lists only contain (), so that IsSubgroup and its derivatives report that these subgroups have no subgroups other than the trivial one. Charley wright@math.uoregon.edu Charles R.B. Wright Department of Mathematics University of Oregon Eugene, OR 97403 From kaym@math.wayne.edu Mon Jun 28 03:19:05 1993 From: kaym@math.wayne.edu "Kay Magaard" Date: Mon, 28 Jun 93 03:19:05 +0200 Subject: generic character tables Dear Forum, when trying to display a generic charater table I got the following: gap> CharTable("Suzuki",8);; gap> S:=last;; gap> DisplayCharTable(S); Error, Record: element 'orders' must have an assigned value at classes := [ 1 .. Length( tbl.orders ) ] ... in DisplayCharTable( S ) called from main loop brk> quit; Do generic charater tables come without tbl.orders? Kay Magaard From sam@math.rwth-aachen.de Mon Jun 28 09:57:51 1993 From: sam@math.rwth-aachen.de "Thomas Breuer" Date: Mon, 28 Jun 93 09:57:51 +0200 Subject: Re: generic character tables Dear Mrs. and Mr. Forum, Kay Magaard writes in his message of today about a problem with 'DisplayCharTable', called with 'CharTable("Suzuki",8)'. He asks > Do generic charater tables come without tbl.orders? This depends on what components are bound in the generic table. In this case, i.e., in 'CharTable("Suzuki")', no representative orders and also no power maps are stored. But of course this should not cause an error in 'DisplayCharTable', and this bug will be fixed in the next version. Kind regards Thomas Breuer (sam@ernie.math.rwth-aachen.de) From gurican@alpha.dcs.mff.uniba.cs Tue Jun 29 12:04:41 1993 From: gurican@alpha.dcs.mff.uniba.cs "Jaroslav Gurican" Date: Tue, 29 Jun 93 12:04:41 +0200 Subject: Error in Manual for GAP 3.1 ? Dear Gap-forum! Reading the GAP 3.1 manual we were trying example at the bottom of the page 91. The example reads as follows: gap> A:=Z(3)*[[0,1],[1,0]];;B:=Z(3)*[[0,1],[-1,0]];; gap> G:=Group(A,B); Group( [ [ 0*Z(3), Z(3) ], [ Z(3), 0*Z(3) ] ], [ [ 0*Z(3), Z(3) ], [ Z(3)^0, 0*Z(3) ] ] ) gap> Size(G); 8 gap> G.name:="G"; "G" gap> d8:=Operation(G,Orbit(G,Z(3)*[1,0])); Group( (1,2)(3,4), (1,2,3,4) ) gap> e:=OperationHomomorphism(Subgroup(G,[B]),d8); OperationHomomorphism( Subgroup( G, [ [ [ 0*Z(3), Z(3) ], [ Z(3)^0, 0*Z(3) ] ] ] ), Group( (1,2)(3,4), (1,2,3,4) ) ) Uptill now things go well. But we don't understand the following error message: gap> Kernel(e); Error, Record: element 'permDomain' must have an assigned value at if not d in G.permDomain ... in stb.operations.Stabilizer( stb, pnt, OnPoints ) called from GroupOps.Stabilizer( G, d, opr ) called from arg[1].operations.Stabilizer( arg[1], arg[2], arg[3] ) called from Stabilizer( hom.source, orb, OnTuples ) called from fun( i ) called from .. brk> The correct answer (according to the manual) is: Subgroup( G, [ ] ) Maybe we are missing some library file? As the example is just rewritten from the manual, it should work. Similar problems occur on the "top example" of the page 94 (the example deals with the same group G as the previuos one). The problem is in the computing of images. GAP computes Image (c, A), but not e.g Image(c, A*B) (the function Image in this example seems to work only with generators A, B). The problem seems to be due to the fact that the matrices are over GF(3). The same things go well for the isomorfic group generated by the same matrices, but over Q. Jaroslav Gurican, Martin Skoviera From fceller@math.rwth-aachen.de Tue Jun 29 17:38:49 1993 From: fceller@math.rwth-aachen.de "Frank Celler" Date: Tue, 29 Jun 93 17:38:49 +0200 Subject: Re: Error in Manual for GAP 3.1 ? Dear Mr. and Ms. forum, >> Uptill now things go well. But we don't understand the following >> error message: >> >> gap> Kernel(e); >> Error, Record: element 'permDomain' must have an assigned value at >> if not d in G.permDomain ... in >> stb.operations.Stabilizer( stb, pnt, OnPoints ) called from >> GroupOps.Stabilizer( G, d, opr ) called from >> arg[1].operations.Stabilizer( arg[1], arg[2], arg[3] ) called from >> Stabilizer( hom.source, orb, OnTuples ) called from >> fun( i ) called from >> .. >> brk> >> >> The problem is in the computing of images. >> GAP computes Image (c, A), but not e.g Image(c, A*B) (the function >> Image in this example seems to work only with generators A, B). This bug was fixed in GAP 3.1 Patchlevel 1: This is the first upgrade for GAP 3.1. It brings version 3 release 1 (V3R1) to version 3 release 1 patchlevel 1 (V3R1P1). The priority of this upgrade is low. [...] The function 'Image' was fixed to test the cases correctly. 'Image' signalled an error when called to compute the image of a matrix under a mapping. Please update to GAP 3.2, or if you do not have ftp access, try at least to upgrade to GAP 3.1 patchlevel 3. best wishes Frank From gurican@alpha.dcs.mff.uniba.cs Wed Jun 30 10:44:01 1993 From: gurican@alpha.dcs.mff.uniba.cs "Jaroslav Gurican" Date: Wed, 30 Jun 93 10:44:01 +0200 Subject: Re: Error in Manual for GAP 3.1 ? Hello Frank, thank you. I know that it is good idea to upgrade to 3.2. I have been trying to get it since february, but there were problems with our ftp connection. But in fact I have all things now, I am missing only grp3r2 library. I hope, I will be able to get it in a few days. (I have problems with files bigger than 25 kBytes or so, but last saturday I've got almost all *.zoo files - I've simply forgot to get grp3r2). You promissed me your paper dealing with cohomology groups at Budapest. I would like to have it (TeX file is enough, of course), if possible. Best wishes, Jaroslav