Goto Chapter: Top 1 2 3 4 5 Bib Ind
 [Top of Book]  [Contents]   [Previous Chapter]   [Next Chapter] 

4 Group Recognition
 4.1 The recursive procedure
 4.2 Recognition info records
 4.3 Methods to find homomorphisms
 4.4 Conventions for the recognition of permutation groups
 4.5 Conventions for the recognition of matrix groups
 4.6 Conventions for the recognition of projective groups
 4.7 Conventions for the recognition of black box groups

4 Group Recognition

This chapter describes a generic framework for group recognition. The basic problem is, we want to solve the constructive membership problem: given any g ∈ G, G = ⟨ X ⟩, write a straight line program (SLP) from X to g, for g ∉ G (in the situation that G is naturally embedded into some bigger group), the algorithm should fail. This is usually done by constructing some nice generators (and then writing an SLP from the nice generators to g and concatenating with an SLP from X to the nice generators). Often, for efficiency reasons, we will just store the nice generators and then only be interested in the SLP from those to g. The framework presented here deals with exactly this process.

The generic framework was designed having four situations in mind: permutation groups, matrix groups, projective groups and black box groups. Although the methods used are quite different for those four cases, there is a common pattern in the procedure of recognition. Namely, first we have to find a homomorphism, solve the constructive membership problem recursively in image and kernel, then put it together. The recursion ends in groups where we can solve the constructive membership problem directly. The general framework reflects this idea and separates it from the rest of the recognition methods.

Solution of the constructive membership problem comes in two stages: first a "recognition phase" and then a "verification phase". The recognition phase usually consists of randomised algorithms with certain error or failure probabilities. The result is some kind of "recognition information" that will describe the group already very well, but which is not yet proven to be correct. However, one can already write arbitrary elements in the group as product of the given generators. In the verification phase a presentation of the group is calculated, thereby proving that the group generated by the given generators is in fact isomorphic to the group described by the recognition information. In many cases the verification phase will be much more expensive than the recognition phase.

In the following sections, we describe the generic framework. We begin with a technical description of the recursive procedure and describe then the way methods to find homomorphism have to be implemented. Finally, we have four sections in which we collect conventions for the recognition of different types of groups.

No actual recognition methods are implemented in this package. See the recog package for an implementation and description of them.

4.1 The recursive procedure

As explained at the beginning of this section, the heart of the recognition procedure is a function called RecogniseGeneric (4.1-1) which gets a GAP group object and returns a so-called "recognition info record" (see Subsection 4.2 for details). Success or failure will be indicated by this record being in the filter IsReady (4.2-4) or not.

To know how to find homomorphisms the function gets as another argument a database of methods (see Section 4.3 for a description of the setup for methods for finding homomorphisms and Section 3.1 in Chapter 3 for details about method databases). This database will be different according to the type of group in question.

To describe the algorithm executed by RecogniseGeneric (4.1-1) we first summarise it in steps:

  1. Create a new, empty recognition info record.

  2. Use the database of FindHomomorphism methods and the method selection procedure described in Chapter 3 to try to find a homomorphism onto a smaller group or an isomorphism onto another known group. Terminate with failure if this does not work.

  3. If an isomorphism is found or a method somehow else recognises the group in question, such that we can write elements as straight line programs in the generators from now on, then make the recognition info record a leaf of the recognition tree and return success.

  4. Otherwise the function sets up all the data for the homomorphism and calls itself with the image of the homomorphism. Note that this might use another database of recognition methods because the homomorphism might change the representation of the group.

  5. After successful recognition of the factor group the procedure has to recognise the kernel of the homomorphism. The first step for this is to find generators. If they are not already known from the FindHomomorphism method, they are created by producing random elements in the group, mapping them through the homomorphism, writing them as a straight line program in the images of the generators and applying this straight line program to the original generators. The quotient of the random element and the result of the straight line program lies in the kernel of the homomorphism. After creating 20 random generators of the kernel we assume for the moment that they generate the kernel.

  6. The function RecogniseGeneric (4.1-1) can now call itself for the kernel. After successful recognition of the kernel all the data for the node is completed and success is returned.

  7. The function RecogniseGeneric (4.1-1) now acquires preimages of the nice generators behind the homomorphism and appends the nice generators of the kernel. This list of generators is now the list of nice generators for the current node.

Note that with the collected data one can write arbitrary elements of the group as a straight line program in the generators as follows:

  1. Map the element through the homomorphism.

  2. Write the element in the factor group as a product of the nice generators in the factor group.

  3. Apply the resulting straight line program to the preimages of those nice generators and calculate the quotient, which will now lie in the kernel.

  4. Write the kernel element as a straight line program in the kernel generators.

  5. Assemble both straight line programs to one bigger straight line program (which is now in terms of our own nice generators) and return it.

If this procedure fails in the fourth step, this indicates that our random generators for the kernel did not yet generate the full kernel and makes further recognition steps necessary. This will not happen after a successful verification phase.

The latter procedure to write elements as straight line programs in the generators is implemented in the function SLPforElementGeneric (4.3-2) which will be called automatically if one calls the SLPforElement (4.2-14) function of the resulting recognition info record (see slpforelement (4.2-13)).

It is now high time to give you the calling details of the main recursive recognition function:

4.1-1 RecogniseGeneric
‣ RecogniseGeneric( H, methoddb, depth[, knowledge] )( function )
‣ RecognizeGeneric( H, methoddb, depth[, knowledge] )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP group object, methoddb must be a method database in the sense of Section 3.1 containing FindHomomorphism methods in the sense of Section 4.3. depth is an integer which measures the depth in the recognition tree. It will be increased by one for each step we go into the tree. The top level has depth 0. knowledge is an optional record the components of which are copied into the new recognition info record which is created for the group H. Especially the component hints can contain a list of additional find homomorphism methods (described by records as in Section 3.1) which is prepended to the method database in methoddb before the recognition starts. This feature is intended to give hints about prior knowledge about which find homomorphism method might succeed.

The function performs the algorithm described above and returns either fail in case of failure or a recognition info record in case of success. For the content and definition of recognition info records see Section 4.2.

The user will usually not call this function directly, but will use the following convenience functions:

4.1-2 RecognisePermGroup
‣ RecognisePermGroup( H )( function )
‣ RecognizePermGroup( H )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP permutation group object. This function calls RecogniseGeneric (4.1-1) with the method database used for permutation groups, which is stored in the global variable FindHomDbPerm (4.1-7), and no prior knowledge.

4.1-3 RecogniseMatrixGroup
‣ RecogniseMatrixGroup( H )( function )
‣ RecognizeMatrixGroup( H )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP matrix group object. This function calls RecogniseGeneric (4.1-1) with the method database used for matrix groups, which is stored in the global variable FindHomDbMatrix (4.1-10), and no prior knowledge.

4.1-4 RecogniseProjectiveGroup
‣ RecogniseProjectiveGroup( H )( function )
‣ RecognizeProjectiveGroup( H )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP matrix group object. Since as of now no actual projective groups are implemented in the GAP library we use matrix groups instead. The recognition will however view the group as the projective group, i.e. the matrix group modulo its scalar matrices. This function calls RecogniseGeneric (4.1-1) with the method database used for projective groups, which is stored in the global variable FindHomDbProjective (4.1-13), and no prior knowledge.

4.1-5 RecogniseBBGroup
‣ RecogniseBBGroup( H )( function )
‣ RecognizeBBGroup( H )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP black box group object. This function calls RecogniseGeneric (4.1-1) with the method database used for black box groups, which is stored in the global variable FindHomDbBB (4.1-16), and no prior knowledge.

4.1-6 RecogniseGroup
‣ RecogniseGroup( H )( function )
‣ RecognizeGroup( H )( function )

Returns: fail for failure or a recognition info record.

H must be a GAP group object. This function automatically dispatches to one of the three previous functions RecognisePermGroup (4.1-2), RecogniseMatrixGroup (4.1-3), or RecogniseBBGroup (4.1-5), according to the type of the group H. Note that since currently there is no implementation of projective groups in the GAP library, one cannot recognise a matrix group H as a projective group using this function.

4.1-7 FindHomDbPerm
‣ FindHomDbPerm( global variable )

This list contains the methods for finding homomorphisms for permutation group recognition that are stored in the record FindHomMethodsPerm (4.1-8). As described in Section 3.1 each method is described by a record. The list is always sorted with respect to decreasing ranks. The order in this list tells in which order the methods should be applied. Use AddMethod (3.1-1) to add methods to this database.

4.1-8 FindHomMethodsPerm
‣ FindHomMethodsPerm( global variable )

In this global record the functions that are methods for finding homomorphisms for permutation group recognition are stored. We collect them all in this record such that we do not use up too many global variable names.

4.1-9 SLPforElementFuncsPerm
‣ SLPforElementFuncsPerm( global variable )

This global record holds the functions that are methods for writing group elements as straight line programs (SLPs) in terms of the generators after successful permutation group recognition. We collect them all in this record such that we do not use up too many global variable names.

4.1-10 FindHomDbMatrix
‣ FindHomDbMatrix( global variable )

This list contains the methods for finding homomorphisms for matrix group recognition that are stored in the record FindHomMethodsMatrix (4.1-11). As described in Section 3.1 each method is described by a record. The list is always sorted with respect to decreasing ranks. The order in this list tells in which order the methods should be applied. Use AddMethod (3.1-1) to add methods to this database.

4.1-11 FindHomMethodsMatrix
‣ FindHomMethodsMatrix( global variable )

In this global record the functions that are methods for finding homomorphisms for matrix group recognition are stored. We collect them all in this record such that we do not use up too many global variable names.

4.1-12 SLPforElementFuncsMatrix
‣ SLPforElementFuncsMatrix( global variable )

This global record holds the functions that are methods for writing group elements as straight line programs (SLPs) in terms of the generators after successful matrix group recognition. We collect them all in this record such that we do not use up too many global variable names.

4.1-13 FindHomDbProjective
‣ FindHomDbProjective( global variable )

This list contains the methods for finding homomorphisms for projective group recognition that are stored in the record FindHomMethodsProjective (4.1-14). As described in Section 3.1 each method is described by a record. The list is always sorted with respect to decreasing ranks. The order in this list tells in which order the methods should be applied. Use AddMethod (3.1-1) to add methods to this database.

4.1-14 FindHomMethodsProjective
‣ FindHomMethodsProjective( global variable )

In this global record the functions that are methods for finding homomorphisms for projective group recognition are stored. We collect them all in this record such that we do not use up too many global variable names.

4.1-15 SLPforElementFuncsProjective
‣ SLPforElementFuncsProjective( global variable )

This global record holds the functions that are methods for writing group elements as straight line programs (SLPs) in terms of the generators after successful projective group recognition. We collect them all in this record such that we do not use up too many global variable names.

4.1-16 FindHomDbBB
‣ FindHomDbBB( global variable )

This list contains the methods for finding homomorphisms for black box group recognition that are stored in the record FindHomMethodsBB (4.1-17). As described in Section 3.1 each method is described by a record. The list is always sorted with respect to decreasing ranks. The order in this list tells in which order the methods should be applied. Use AddMethod (3.1-1) to add methods to this database.

4.1-17 FindHomMethodsBB
‣ FindHomMethodsBB( global variable )

In this global record the functions that are methods for finding homomorphisms for black box group recognition are stored. We collect them all in this record such that we do not use up too many global variable names.

4.1-18 SLPforElementFuncsBB
‣ SLPforElementFuncsBB( global variable )

This global record holds the functions that are methods for writing group elements as straight line programs (SLPs) in terms of the generators after successful black box group recognition. We collect them all in this record such that we do not use up too many global variable names.

4.1-19 TryFindHomMethod
‣ TryFindHomMethod( H, method, projective )( function )

Returns: fail or false or a recognition info record.

Use this function to try to run a given find homomorphism method method on a group H. Indicate by the boolean projective whether or not the method works in projective mode. For permutation and black box groups give false. The result is either fail or false if the method fails or a recognition info record ri. If the method created a leaf then ri will be a leaf, otherwise it will have the attribute Homom (4.2-6) set, but no factor or kernel have been created or recognised yet. You can use for example the methods in FindHomMethodsPerm (4.1-8) or FindHomMethodsMatrix (4.1-11) or FindHomMethodsProjective (4.1-14) or FindHomMethodsBB (4.1-17) as the method argument.

4.2 Recognition info records

A recognition info record is a GAP positional object. It is a member of the family

4.2-1 RecognitionInfoFamily
‣ RecognitionInfoFamily( family )

and is in the category

4.2-2 IsRecognitionInfo
‣ IsRecognitionInfo( category )

and is IsAttributeStoringRep (Reference: IsAttributeStoringRep), such that we can define attributes for it, the values of which are stored once they are known. A recognition info record always represents a whole binary tree of such records, see the attributes RIFac (4.2-9) and RIKer (4.2-10) below.

The following filters are defined for recognition info records:

4.2-3 IsLeaf
‣ IsLeaf( flag )

This flag indicates, whether or not a recognition info record represents a leaf in the recognition tree. If it is not set, one finds at least one of the attributes RIFac (4.2-9) and RIKer (4.2-10) set for the corresponding node. This flag is normally reset and has to be set by a find homomorphism method to indicate a leaf.

4.2-4 IsReady
‣ IsReady( flag )

This flag indicates during the recognition procedure, whether a node in the recognition tree is already completed or not. It is mainly set for debugging purposes during the recognition. However, if the recognition fails somewhere in a leaf, this flag is not set and all nodes above will also not have this flag set. In this way one can see whether the recognition failed and where the problem was. If a find homomorphism method uses donotrecurse (see 4.2-33) to avoid further recursion it acquires thereby responsibility to set the IsReady flag in the corresponding subtree upon completion.

The following attributes are defined for recognition info records:

4.2-5 Grp
‣ Grp( ri )( attribute )

The value of this attribute is the group that is to be recognised by this recognition info record ri. This attribute is always present during recognition and after completion. Note that the generators of the group object stored here always have a memory attached to them, such that elements that are generated from them remember, how they were acquired.

4.2-6 Homom
‣ Homom( ri )( attribute )

The value of this attribute is the homomorphism that was found from the group described by the recognition info record ri as a GAP object. It is set by a find homomorphism method that succeeded to find a homomorphism (or isomorphism). It does not have to be set in leaf nodes of the recognition tree.

4.2-7 NiceGens
‣ NiceGens( ri )( attribute )

The value of this attribute must be set for all nodes and contains the nice generators. The SLPforElement (4.2-14) function of the node will write its straight line program in terms of these nice generators. For leaf nodes, the find homomorphism method is responsible to set the value of NiceGens. By default, the original generators of the group at this node are taken. For a homomorphism (or isomorphism), the NiceGens will be the concatenation of preimages of the NiceGens of the factor group (see pregensfac (4.2-8)) and the NiceGens of the kernel. A find homomorphism method does not have to set NiceGens if it finds a homomorphism. Note however, that such a find homomorphism method has to ensure somehow, that preimages of the NiceGens of the factor group can be acquired. See calcnicegens (4.2-17), CalcNiceGens (4.2-20) and slptonice (4.2-21) for instructions.

4.2-8 pregensfac
‣ pregensfac( ri )( attribute )

The value of this attribute is only set for homomorphism nodes. In that case it contains preimages of the nice generators in the factor group. This attribute is set automatically by the generic recursive recognition function using the mechanism described with the attribute calcnicegens (4.2-17) below. A find homomorphism does not have to touch this attribute.

4.2-9 RIFac
‣ RIFac( ri )( attribute )

The value of this attribute is the recognition info record of the image of the homomorphism that was found from the group described by the recognition info record ri. It is set by the generic recursive procedure after a find homomorphism method has succeeded to find a homomorphism (or isomorphism). It does not have to be set in leaf nodes of the recognition tree. This attribute value provides the link to the "factor" subtree of the recognition tree.

4.2-10 RIKer
‣ RIKer( ri )( attribute )

The value of this attribute is the recognition info record of the kernel of the homomorphism that was found from the group described by the recognition info record ri. It is set by the generic recursive procedure after a find homomorphism method has succeeded to find a homomorphism (or isomorphism). It does not have to be set in leaf nodes of the recognition tree or if the homomorphism is known to be an isomorphism. In the latter case the value of the attribute is set to fail. This attribute value provides the link to the "kernel" subtree of the recognition tree.

4.2-11 RIParent
‣ RIParent( ri )( attribute )

The value of this attribute is the recognition info record of the parent of this node in the recognition tree. The top node does not have this attribute set.

4.2-12 fhmethsel
‣ fhmethsel( ri )( attribute )

The value of this attribute is the record returned by the method selection (see Section 3.2) after it ran to find a homomorphism (or isomorphism). It is there to be able to see which methods were tried until the recognition of the node was completed.

4.2-13 slpforelement
‣ slpforelement( ri )( attribute )

After the recognition phase is completed for the node ri, we are by definition able to write arbitrary elements in the group described by this node as a straight line program (SLP) in terms of the nice generators stored in NiceGens (4.2-7). This attribute value is a function taking the node ri and a group element as its arguments and returning the above mentioned straight line program. For the case that a find homomorphism method succeeds in finding a homomorphism, the generic recursive function sets this attribute to the function SLPforElementGeneric (4.3-2) which does the job for the generic homomorphism situation. In all other cases the successful find homomorphism method has to set this attribute to a function doing the job. The find homomorphism method is free to store additional data in the recognition info record or the group object such that the SLPforElement (4.2-14) function can work.

4.2-14 SLPforElement
‣ SLPforElement( ri, x )( function )

Returns: a straight line program expressing x in the nice generators.

This is a wrapper function which extracts the value of the attribute slpforelement (4.2-13) and calls that function with the arguments ri and x.

4.2-15 StdPresentation
‣ StdPresentation( ri )( attribute )

After the verification phase, the presentation is stored here. Details have still to be decided upon.

4.2-16 methodsforfactor
‣ methodsforfactor( ri )( attribute )

This attribute is initialised at the beginning of the recursive recognition function with the database of find homomorphism methods that was used to recognise the group corresponding to the recognition info record ri. If the found homomorphism changes the representation of the group (going for example from a matrix group to a permutation group), the find homomorphism method can report this by exchanging the database of find homomorphism methods to be used in the recognition of the image of the homomorphism by setting the value of this attribute to something different. It lies in the responsibility of the find homomorphism method to do so, if the representation changes through the homomorphism.

The following two attributes are concerned with the relation between the original generators and the nice generators for a node. They are used to transport this information from a successful find homomorphism method up to the recursive recognition function:

4.2-17 calcnicegens
‣ calcnicegens( ri )( attribute )

To make the recursion work, we have to acquire preimages of the nice generators in factor groups under the homomorphism found. But we want to keep the information, how the nice generators were found, locally at the node where they were found. This attribute solves this problem of acquiring preimages in the following way: Its value must be a function, taking the recognition info record ri as first argument, and a list origgens of preimages of the original generators of the current node, and has to return corresponding preimages of the nice generators. Usually this task can be done by storing a straight line program writing the nice generators in terms of the original generators and executing this with inputs origgens. Therefore the default value of this attribute is the function CalcNiceGensGeneric (4.2-18) described below.

4.2-18 CalcNiceGensGeneric
‣ CalcNiceGensGeneric( ri, origgens )( function )

Returns: a list of preimages of the nice generators

This is the default function for leaf nodes for the attribute calcnicegens (4.2-17) described above. It does the following: If the value of the attribute slptonice (4.2-21) is set, then it must be a straight line program expressing the nice generators in terms of the original generators of this node. In that case, this straight line program is executed with origgens as inputs and the result is returned. Otherwise, origgens is returned as is. Therefore a leaf node just has to do nothing if the nice generators are equal to the original generators, or can simply store the right straight line program into the attribute slptonice (4.2-21) to fulfill its duties.

4.2-19 CalcNiceGensHomNode
‣ CalcNiceGensHomNode( ri, origgens )( function )

Returns: a list of preimages of the nice generators

This is the default function for homomorphism node for the attribute calcnicegens (4.2-17). It just delegates to factor and kernel of the homomorphism, as the nice generators of a homomorphism (or isomorphism) node are just the concatenation of the nice generators of the factor and the kernel. A find homomorphism method finding a homomorphism or isomorphism does not have to do anything with respect to nice generators.

4.2-20 CalcNiceGens
‣ CalcNiceGens( ri, origgens )( function )

Returns: a list of preimages of the nice generators

This is a wrapper function which extracts the value of the attribute calcnicegens (4.2-17) and calls that function with the arguments ri and origgens.

4.2-21 slptonice
‣ slptonice( ri )( attribute )

As described above, the value, if set, must be a straight line program expressing the nice generators at this node in terms of the original generators. This is for leaf nodes, that choose to use the default function CalcNiceGensGeneric (4.2-18) installed in the calcnicegens (4.2-17) attribute.

The following three attributes are concerned with the administration of the kernel of a found homomorphism. Find homomorphism methods use them to report to the main recursive recognition function their knowledge about the kernel:

4.2-22 gensN
‣ gensN( ri )( attribute )

The value of this mutable attribute is a list of generators of the kernel of the homomorphism found at the node ri. It is initialised as an empty list when the recursive recognition function starts. Successful find homomorphism methods may append generators of the kernel to this list if they happen to stumble on them. After successful recognition of the image of the homomorphism the main recursive recognition function will try to create a few more generators of the kernel and append them to the list which is the value of the attribute gensN. The exact behaviour depends on the value of the attribute findgensNmeth (4.2-23) below. The list of generators after that step is used to recognise the kernel. Note that the generators in gensN have a memory attached to them, how they were obtained in terms of the original generators of the current node.

4.2-23 findgensNmeth
‣ findgensNmeth( ri )( attribute )

This attribute decides about how generators of the kernel of a found homomorphism are produced. Its value has to be a record with at least two components bound. The first is method which holds a function taking at least one argument ri and possibly more, and does not return anything. The second is args which holds a list of arguments for the above mentioned function. The real list of arguments is derived by prepending the recognition info record to the list of arguments in args. That is, the following code is used to call the method:

    methgensN := findmethgensN(ri);
    CallFuncList(methgensN(ri).method,Concatenation([ri],methgensN.args));

The record is initialised upon creation of the recognition info record to calling FindKernelRandom (4.2-24) with one argument of 20 (in addition to the first argument ri). See below for a choice of possible find kernel methods.

4.2-24 FindKernelRandom
‣ FindKernelRandom( ri, n )( function )

Returns: nothing

n random elements are generated, mapped through the homomorphism, written as a straight line program in the generators. Then the straight line program is executed with the original generators thereby producing elements in the same coset. The quotients are then elements of the kernel. The kernel elements created are stored in the attribute gensN (4.2-22).

4.2-25 FindKernelDoNothing
‣ FindKernelDoNothing( ri, n )( function )

Returns: nothing

Does nothing. This function is intended to be set as method for producing kernel elements if the kernel is known to be trivial or if one knows, that the attribute gensN (4.2-22) already contains a complete set of generators for the kernel.

4.2-26 FindKernelFastNormalClosure
‣ FindKernelFastNormalClosure( ri, nr )( function )

Returns: a probable generating set for the normal closure

This function takes the group G in the Grp (4.2-5) attribute in ri and the list of generators gens of the kernel in gensN (4.2-22) and the positive integer nr. This function computes a probable generating set of the normal closure in G of the group generated by the generators in gens. The integer nr indicates how hard it should try.

4.2-27 gensNslp
‣ gensNslp( ri )( attribute )

The recursive recognition function calculates a straight line program that computes the generators of the kernel stored in gensN (4.2-22) in terms of the generators of the group recognised by ri. This straight line program is stored in the value of this mutable attribute. It is used by the generic function SLPforElementGeneric (4.3-2).

4.2-28 immediateverification
‣ immediateverification( ri )( attribute )

Sometimes a find homomorphism has information that it will be difficult to create generators for the kernel, for example if it is known that the kernel will need lots of generators. In that case this attribute with the default boolean value false can be set to true. In that case, the generic recursive recognition function will perform an immediate verification phase after the kernel has been recognised. This is done as follows: A few random elements are created, mapped through the homomorphism and written as an SLP in the nice generators there. Then this SLP is executed with preimages of those nice generators. The quotient lies then in the kernel and is written as an SLP in terms of the nice generators of the would be kernel. If this is not possible, then probably the creation of kernel generators was not complete and a few more kernel elements are produced and recognition in the kernel starts all over again. This is for example done in case of the "Imprimitive" method which maps onto the action on a block system. In that case, the kernel often needs lots of generators.

The following attributes are used to give a successful find homomorphism method further possibilities to transport knowledge about the group recognised by the current recognition info record to the factor or kernel of the found homomorphism:

4.2-29 forkernel
‣ forkernel( ri )( attribute )

This attribute is initialised to a record with only the component hints bound to an empty list at the beginning of the recursive recognition function. Find homomorphism methods can put acquired knowledge about the group to be recognised (like for example an invariant subspace of a matrix group) into this record. When a homomorphism is found and recognition goes on in its kernel, the value of this attribute is taken as initialisation data for the newly created recognition info record for the kernel. Thus, information is transported down to the recognition process for the kernel. The component hints is special insofar as it has to contain records describing find homomorphism methods which might be particularly successful. They are prepended to the find homomorphism method database such that they are called before any other methods. This is a means to give hints to the recognition procedure in the kernel, because often during the finding of a homomorphism knowledge is acquired which might help the recognition of the kernel.

4.2-30 forfactor
‣ forfactor( ri )( attribute )

This attribute is initialised to a record with only the component hints bound to an empty list at the beginning of the recursive recognition function. Find homomorphism methods can put acquired knowledge about the group to be recognised (like for example an invariant subspace of a matrix group) into this record. When a homomorphism is found and recognition goes on in its image, the value of this attribute is taken as initialisation data for the newly created recognition info record for the factor. Thus, information is transported down to the recognition process for the factor. The component hints is special insofar as it has to contain records describing find homomorphism methods which might be particularly successful. They are prepended to the find homomorphism method database such that they are called before any other methods. This is a means to give hints to the recognition procedure in the factor, because often during the finding of a homomorphism knowledge is acquired which might help the recognition of the factor.

4.2-31 isone
‣ isone( ri )( attribute )

This attribute returns a function that tests, whether or not an element of the group is equal to the identity or not. Usually this is just the operation IsOne (Reference: IsOne) but for projective groups it is a special function returning true for scalar matrices. In generic code, one should always use the result of this attribute to compare an element to the identity such that the code works also for projective groups. Find homomorphism methods usually do not have to set this attribute.

4.2-32 isequal
‣ isequal( ri )( attribute )

This attribute returns a function that compares two elements of the group being recognised. Usually this is just the operation EQ (Reference: Equality and inequality of Booleans) but for projective groups it is a special function checking for equality up to a scalar factor. In generic code, one should always use the result of this attribute to compare two elements such that the code works also for projective groups. Find homomorphism methods usually do not have to set this attribute.

4.2-33 Other components of recognition info records

In this subsection we describe a few more components of recognition info records that can be queried or set by find homomorphism methods. Not all of these components are bound in all cases. See the individual descriptions about the conventions. Remember to use the !. notation to access these components of a recognition info record.

donotrecurse

This component can be set to true by a find homomorphism method to indicate that the generic recursive procedure should not recurse further down, even if the corresponding node is not a leaf. It is then the responsibility of the find homomorphism method to complete the tree below.

leavegensNuntouched

If this component is bound to true by a find homomorphism method or a find kernel generators method, the generic mechanism to remove duplicates and identities in the generator for the kernel is not used. This is important if your methods rely on the generating set of the kernel being exactly as it was when found.

4.3 Methods to find homomorphisms

A "find homomorphism method" has the objective to, given a group G, either find a homomorphism from G onto a group, or to find an isomorphism, or to solve the constructive membership problem directly for G, or to fail.

In case a homomorphism is found, it has to report that homomorphism back to the calling recursive recognition function together with as much information about the kernel as possible.

If a find homomorphism method determines that the node is a leaf in the recognition tree (by solving the constructive membership problem directly), then it has to ensure, that arbitrary elements can be written in terms of the nice generators of G. It does so by returning a function together with possible extra data, that can perform this job.

Of course, the find homomorphism method also has to report, how the nice generators were acquired in terms of the original generators.

If the find homomorphism method fails, it has to report, whether it has failed forever or if it possibly makes sense to try to call this method again later.

Find homomorphism methods have to fit into the framework for method selection described in Chapter 3. We now begin to describe the technical details of how a find homomorphism method has to look like and what it has to do and what it is not allowed to do. We first explain the calling convention by means of a hypothetical function:

4.3-1 FindHomomorphism
‣ FindHomomorphism( ri, G )( function )

Returns: One of the values true, false, fail, or NotApplicable.

Find homomorphism methods take two arguments ri and G, of which ri is a recognition info record and G is a GAP group object. The return value is one of the four possible values in the framework for method selection described in Chapter 3 indicating success, failure, or (temporary) non-applicability. The above mentioned additional information in case of success are all returned by changing the recognition info record ri. For the conventions about what a find homomorphism method has to do and return see below.

A failed or not applicable find homomorphism method does not have to report or do anything in the recognition info record ri. However, it can collect information and store it either in the group object or in the recognition info record. Note that for example it might be that a failed find homomorphism method acquires additional information that allows another find homomorphism method to become applicable.

A not applicable find homomorphism method should find out so relatively quickly, because otherwise the whole process might be slowed down, because a find homomorphism method repeatedly ponders about its applicability. Usually no big calculations should be triggered just to decide applicability.

A successful find homomorphism method has the following duties:

for leaves:

First it has to report whether the current node is a leaf or not in the recognition tree. That is, in case a leaf was found the method has to do SetFilterObj(ri,IsLeaf); thereby setting the IsLeaf (4.2-3) flag.

If the method for some reason chooses to finish the tree below the current node on its own, it can set the component donotrecurse to true (see 4.2-33) to indicate that no further action is required by the generic recognition function. The method is then responsible for correctly setting the IsLeaf (4.2-3) and IsReady (4.2-4) flags in the whole subtree.

A method finding a homomorphism which is not an isomorphism indicates so by not touching the flags.

for leaves: SLPforElement (4.2-14) function

If a find homomorphism method has produced a leaf in the recognition tree or has set the donotrecurse component to true (see 4.2-33), then it has to set the attribute slpforelement (4.2-13) to a function like SLPforElementGeneric (4.3-2) that can write an arbitrary element in G as a straight line program in the nice generators of G. The method may store additional data into the recognition info record for this to work. It does not have to set any other value in ri.

for leaves: information about nice generators

If a find homomorphism method has produced a leaf in the recognition tree, then it has to report what are the nice generators of the group described by the leaf. To this end, it has three possibilities: Firstly to do nothing, which means, that the original generators are the nice generators. Secondly to store a straight line program expressing the nice generators in terms of the original generators into the attribute slptonice (4.2-21). In that case, the generic frame work takes care of the rest. The third possibility is to store a function into the value of the attribute calcnicegens (4.2-17) which can calculate preimages of the nice generators in terms of preimages of the original generators. See the function CalcNiceGensGeneric (4.2-18) for an example of such a function.

for non-leaves: the homomorphism itself

If a find homomorphism method has found a homomorphism, it has to store it as a GAP homomorphism object from G to the image group in the attribute Homom (4.2-6). Note that if your homomorphism changes the representation (for example going from matrix groups to permutation groups), you will have to set the attribute methodsforfactor (4.2-16) accordingly.

for non-leaves: kernel generators

If a find homomorphism method has found a homomorphism, it has to provide information about already known generators of the kernel. This is done firstly by appending known generators of the kernel to the attribute value of gensN (4.2-22) and secondly by leaving or changing the attribute findgensNmeth (4.2-23) to a record describing the method that should be used (for details see findgensNmeth (4.2-23)). If one does not change the default value, the recursive recognition function will generate 20 random elements in G and produce random generators of the kernel by dividing by a preimage of an image under the homomorphism. Note that generators in gensN (4.2-22) have to have a memory attached to them that stores, how they were acquired from the generators of G.

additional information

A find homomorphism method may store any data into the attributes forkernel (4.2-29) and forfactor (4.2-30), which both are records. Components in these record that are bound during the recognition will be copied into the recognition info record of the kernel and factor respectively of a found homomorphism upon creation and thus are available to all find homomorphism methods called for the kernel and factor. This feature might be interesting to transport information that is relevant for the recognition of the kernel or factor and was acquired during the recognition of G itself.

A special role is played by the component hints in both of the above records, which can hold a list of records describing find homomorphism methods that shall be tried first when recognising the kernel or factor.

In addition, a find homomorphism method might set the attribute immediateverification (4.2-28) to true, if it considers the problem of finding kernel generators particularly difficult.

To explain the calling conventions for SLPforElement (4.2-14) functions and for the sake of completeness we present now the function SLPforElementGeneric (4.3-2) which is used for the case of a "homomorphism node":

4.3-2 SLPforElementGeneric
‣ SLPforElementGeneric( ri, x )( function )

Returns: a GAP straight line program

This function takes as arguments a recognition info record ri and a group element x. It returns a GAP straight line program that expresses the element x in terms of the nice generators of the group G recognised by ri.

This generic function here does exactly this job for the generic situation that we found a homomorphism from G to some other group say H with kernel N. It first maps x via the homomorphism to H and uses the recognition information there to write it as a straight line program in terms of the nice generators of H. Then it applies this straight line program to the preimages of those nice generators (see pregensfac (4.2-8)) thereby finding an element y of G with x ⋅ y^-1 lying in the kernel N.

Then the function writes this element as a straight line program in the nice generators of N again using the recursively acquired recognition info about N. In the end a concatenated straight line program for x is built, which is in terms of the nice generators of the current node.

4.4 Conventions for the recognition of permutation groups

No conventions so far.

4.5 Conventions for the recognition of matrix groups

We are considering only the case of matrix groups over finite fields.

No conventions so far.

4.6 Conventions for the recognition of projective groups

We are considering only the case of projective groups over finite fields.

No conventions so far.

4.7 Conventions for the recognition of black box groups

No conventions so far.

 [Top of Book]  [Contents]   [Previous Chapter]   [Next Chapter] 
Goto Chapter: Top 1 2 3 4 5 Bib Ind

generated by GAPDoc2HTML