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.
Recognition methods lie in the filter IsRecogMethod (4.1-1) and can be created via the function RecogMethod (4.1-2).
‣ IsRecogMethod | ( category ) |
The category of recognition methods, that is of the objects created via RecogMethod (4.1-2).
‣ 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:
Successmeans that the method was successful and no more methods have to be tried.
NeverApplicablemeans that the method was not successful and that there is no point to call the method again in this situation whatsoever.
TemporaryFailuremeans 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.
NotEnoughInformationmeans 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).
‣ 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.
‣ Stamp( method ) | ( attribute ) |
The stamp of method, see RecogMethod (4.1-2). The argument method must lie in IsRecogMethod (4.1-1).
‣ Comment( method ) | ( attribute ) |
The comment of method, see RecogMethod (4.1-2). The argument method must lie in IsRecogMethod (4.1-1).
‣ 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).
A method database is a list of records, where each record has the following components:
methodA recognition method created with RecogMethod (4.1-2).
rankAn 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.
‣ 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.
‣ FindHomDbPerm | ( global variable ) |
The method database for permutation groups.
‣ FindHomDbMatrix | ( global variable ) |
The method database for matrix groups.
‣ FindHomDbProjective | ( global variable ) |
The method database for projective matrix groups.
Whenever the method selection shall be used, one calls the following function:
‣ 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:
inapplicableMethodsa record, in which for every method that returned NeverApplicable the value 1 is bound to the component with name the stamp of the method.
failedMethodsa 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).
successMethodthe stamp of the method that succeeded, if one did. This component is only bound after successful completion.
resulta 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.
tolerancethe 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:
NeverApplicablethis is marked in the method selection record and the main loop starts again at the beginning of the method database.
TemporaryFailurethis is counted in the method selection record and the main loop starts again at the beginning of the method database.
NotEnoughInformationthe main loop goes to the next method in the method database.
Successthis 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.
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.
‣ FindHomMethodsPerm | ( global variable ) |
Stores recog methods for permutation groups.
‣ FindHomMethodsMatrix | ( global variable ) |
Stores recog methods for matrix groups.
‣ FindHomMethodsProjective | ( global variable ) |
Stores recog methods for projective groups.
‣ 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.
‣ SLPforElementFuncsPerm | ( global variable ) |
Stores the SLP functions for permutation groups.
‣ SLPforElementFuncsMatrix | ( global variable ) |
Stores the SLP functions for matrix groups.
‣ SLPforElementFuncsProjective | ( global variable ) |
Stores the SLP functions for projective groups.
‣ SLPforElementFuncsGeneric | ( global variable ) |
Stores the SLP functions for generic groups.
generated by GAPDoc2HTML