GAP (recog) - Chapter 4: Method selection

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

[MathJax off]

4 Method selection
4.1 What are methods?
4.1-1 IsRecogMethod
4.1-2 RecogMethod
4.1-3 BindRecogMethod
4.1-4 Stamp
4.1-5 Comment
4.1-6 CallRecogMethod
4.2 Method Databases
4.2-1 AddMethod
4.2-2 FindHomDbPerm
4.2-3 FindHomDbMatrix
4.2-4 FindHomDbProjective
4.3 How methods are called
4.3-1 CallMethods
4.4 Global records storing functions
4.4-1 FindHomMethodsPerm
4.4-2 FindHomMethodsMatrix
4.4-3 FindHomMethodsProjective
4.4-4 FindHomMethodsGeneric
4.4-5 SLPforElementFuncsPerm
4.4-6 SLPforElementFuncsMatrix
4.4-7 SLPforElementFuncsProjective
4.4-8 SLPforElementFuncsGeneric

### 4 Method selection

The setup described in this chapter is intended for situations, in which lots of different methods are available to fulfill a certain task, but in which it is not possible in the beginning to decide, which one to use. Therefore this setup regulates, rather than just which method to choose, in which order the various methods are tried. The methods themselves return whether they were successful and, if not, whether it is sensible to try them again at a later stage.

The design is intentionally kept as simple as possible and at the same time as versatile as possible, thereby providing a useful framework for many situations as described above.

Note the differences to the GAP method selection, which is designed with the idea in mind that it will be quite clear in most situations, which one is "the best" method for a given set of input data, and that we do not want to try different things. On the other hand, the GAP method selection is quite complicated, which is to some extend necessary to make sure, that lots of different information about the objects in question can be used to really find the best method.

Our setup here in particular has to fulfill the requirement, that in the end, with lots of methods installed, one still has to be able to have an overview and to "prove", that the whole system always does the right thing.

#### 4.1 What are methods?

Recognition methods lie in the filter `IsRecogMethod` (4.1-1) and can be created via the function `RecogMethod` (4.1-2).

##### 4.1-1 IsRecogMethod

`‣ IsRecogMethod` | ( category )

The category of recognition methods, that is of the objects created via `RecogMethod` (4.1-2).

##### 4.1-2 RecogMethod

`‣ RecogMethod`( stamp, comment, func ) | ( function )

Return a recognition method `method` in the filter `IsRecogMethod` (4.1-1), where stamp is a string describing the method uniquely, comment is a string explaining how the method works, and func is the method itself. The components stamp and comment can be accessed via the attributes `Stamp` (4.1-4) and `Comment` (4.1-5).

A recognition method returns one of the following four values:

`Success`

  means that the method was successful and no more methods have to be tried.

`NeverApplicable`

  means that the method was not successful and that there is no point to call the method again in this situation whatsoever.

`TemporaryFailure`

  means that the method temporarily failed, that it however could be sensible to call it again in this situation at a later stage. This value is typical for a Las Vegas algorithm using randomised methods, which has failed, but which may succeed when called again.

`NotEnoughInformation`

  means that the method for some reason refused to do its work. However, it is possible that it will become applicable later such that it makes sense to call it again, for example when more information is available.

A recognition method `method` should always be stored into the component `Stamp(method)` of one of the following records: `FindHomMethodsGeneric` (4.4-4), `FindHomMethodsPerm` (4.4-1), `FindHomMethodsMatrix` (4.4-2), and `FindHomMethodsProjective` (4.4-3). To this end one can use the function `BindRecogMethod` (4.1-3).

##### 4.1-3 BindRecogMethod

`‣ BindRecogMethod`( r, arg ) | ( function )

Create the recognition method `method` by calling `RecogMethod` (4.1-2) with arguments arg. Then bind the component `Stamp(method)` of r to method.

##### 4.1-4 Stamp

`‣ Stamp`( method ) | ( attribute )

The stamp of method, see `RecogMethod` (4.1-2). The argument method must lie in `IsRecogMethod` (4.1-1).

##### 4.1-5 Comment

`‣ Comment`( method ) | ( attribute )

The comment of method, see `RecogMethod` (4.1-2). The argument method must lie in `IsRecogMethod` (4.1-1).

##### 4.1-6 CallRecogMethod

`‣ CallRecogMethod`( m, args ) | ( function )

Call `UnpackRecogMethod(m)` with arguments args and return the return value. The argument m must lie in `IsRecogMethod` (4.1-1).

#### 4.2 Method Databases

A method database is a list of records, where each record has the following components:

`method`

  A recognition method created with `RecogMethod` (4.1-2).

`rank`

  An integer used to sort the various methods. Higher numbers mean that the method is tried earlier. See `CallMethods` (4.3-1) for information on how the methods are called.

The databases are always sorted such that the ranks are decreasing. Use `AddMethod` (4.2-1) to add a method to a database according to its rank.

##### 4.2-1 AddMethod

`‣ AddMethod`( methodDb, method, rank ) | ( function )

Add the recognition method method with rank rank to the method database methodDb. Return nothing. method is inserted into methodDb such that the ranks of its entries are in decreasing order. For information on recognition methods and method databases see `RecogMethod` (4.1-2) and Section 4.2, respectively.

The following databases contain the methods for finding homomorphisms for permutation, matrix, and projective groups.

##### 4.2-2 FindHomDbPerm

`‣ FindHomDbPerm` | ( global variable )

The method database for permutation groups.

##### 4.2-3 FindHomDbMatrix

`‣ FindHomDbMatrix` | ( global variable )

The method database for matrix groups.

##### 4.2-4 FindHomDbProjective

`‣ FindHomDbProjective` | ( global variable )

The method database for projective matrix groups.

#### 4.3 How methods are called

Whenever the method selection shall be used, one calls the following function:

##### 4.3-1 CallMethods

`‣ CallMethods`( db, limit[, furtherargs] ) | ( function )

Returns: a record `ms` describing this method selection procedure.

The argument db must be a method database in the sense of Section 4.2. limit must be a non-negative integer. furtherargs stands for an arbitrary number of additional arguments, which are handed down to the called methods. Of course they must fulfill the conventions defined for the methods in the database db.

The function first creates a "method selection" record keeping track of the things that happened during the method trying procedure, which is also used during this procedure. Then it calls methods with the algorithm described below and in the end returns the method selection record in its final state.

The method selection record has the following components:

`inapplicableMethods`

  a record, in which for every method that returned `NeverApplicable` the value 1 is bound to the component with name the stamp of the method.

`failedMethods`

  a record, in which for every time a method returned `TemporaryFailure` the value bound to the component with name the stamp of the method is increased by 1 (not being bound means zero).

`successMethod`

  the stamp of the method that succeeded, if one did. This component is only bound after successful completion.

`result`

  a boolean value which is either `Success` or `TemporaryFailure` depending on whether a successful method was found or the procedure gave up respectively. This component is only bound after completion of the method selection procedure.

`tolerance`

  the number of times all methods failed until one succeeded. See below.

The algorithm used by `CallMethods` is extremely simple: It sets a counter `tolerance` to zero. The main loop starts at the beginning of the method database and runs through the methods in turn. Provided a method did not yet return `NeverApplicable` and did not yet return `TemporaryFailure` more than `tolerance` times before, it is tried. According to the value returned by the method, the following happens:

`NeverApplicable`

  this is marked in the method selection record and the main loop starts again at the beginning of the method database.

`TemporaryFailure`

  this is counted in the method selection record and the main loop starts again at the beginning of the method database.

`NotEnoughInformation`

  the main loop goes to the next method in the method database.

`Success`

  this is marked in the method selection record and the procedure returns successfully.

If the main loop reaches the end of the method database without calling a method (because all methods have already failed or are not applicable), then the counter `tolerance` is increased by one and everything starts all over again. This is repeated until `tolerance` is greater than the `limit` which is the second argument of `CallMethods`. The last value of the `tolerance` counter is returned in the component `tolerance` of the method selection record.

Note that the main loop starts again at the beginning of the method database after each failed method call! However, this does not lead to an infinite loop, because the failure is recorded in the method selection record such that the method is skipped until the `tolerance` increases. Once the `tolerance` has been increased methods having returned `TemporaryFailure` will be called again. The idea behind this approach is that even failed methods can collect additional information about the arguments changing them accordingly. This might give methods that come earlier and were not applicable up to now the opportunity to begin working. Therefore one can install very good methods that depend on some already known knowledge which will only be acquired during the method selection procedure by other methods, with a high rank.

#### 4.4 Global records storing functions

The following global records store the methods for finding homomorphisms for group recognition. We collect them in these records such that we do not use up too many global variable names.

##### 4.4-1 FindHomMethodsPerm

`‣ FindHomMethodsPerm` | ( global variable )

Stores recog methods for permutation groups.

##### 4.4-2 FindHomMethodsMatrix

`‣ FindHomMethodsMatrix` | ( global variable )

Stores recog methods for matrix groups.

##### 4.4-3 FindHomMethodsProjective

`‣ FindHomMethodsProjective` | ( global variable )

Stores recog methods for projective groups.

##### 4.4-4 FindHomMethodsGeneric

`‣ FindHomMethodsGeneric` | ( global variable )

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

The following global records hold the functions for writing group elements as straight line programs (SLPs) in terms of the generators after successful group recognition. We collect them in these records such that we do not use up too many global variable names.

##### 4.4-5 SLPforElementFuncsPerm

`‣ SLPforElementFuncsPerm` | ( global variable )

Stores the SLP functions for permutation groups.

##### 4.4-6 SLPforElementFuncsMatrix

`‣ SLPforElementFuncsMatrix` | ( global variable )

Stores the SLP functions for matrix groups.

##### 4.4-7 SLPforElementFuncsProjective

`‣ SLPforElementFuncsProjective` | ( global variable )

Stores the SLP functions for projective groups.

##### 4.4-8 SLPforElementFuncsGeneric

`‣ SLPforElementFuncsGeneric` | ( global variable )

Stores the SLP functions for generic groups.

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

generated by GAPDoc2HTML