GAP (ref) - Chapter 78: Method Selection

Goto Chapter: Top 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 Bib Ind
[Top of Book] [Contents] [Previous Chapter] [Next Chapter]

[MathJax on]

78 Method Selection
78.1 Operations and Methods
78.1-1 IsOperation
78.1-2 TypeOfOperation
78.1-3 ShowDeclarationsOfOperation
78.1-4 NewOperation
78.1-5 DeclareOperation
78.1-6 Tag Based Operations
78.2 Constructors
78.2-1 NewConstructor
78.2-2 DeclareConstructor
78.3 Method Installation
78.3-1 InstallMethod
78.3-2 InstallOtherMethod
78.3-3 InstallEarlyMethod
78.3-4 InstallMethodWithRandomSource
78.4 Applicable Methods and Method Selection
78.5 Partial Methods
78.5-1 TryNextMethod
78.6 Redispatching
78.6-1 RedispatchOnCondition
78.7 Immediate Methods
78.7-1 InstallImmediateMethod
78.7-2 IsNoImmediateMethodsObject
78.8 Logical Implications
78.8-1 InstallTrueMethod
78.8-2 SuspendMethodReordering
78.9 Operations and Mathematical Terms

### 78 Method Selection

This chapter explains how GAP decides which function to call for which types of objects. It assumes that you have read the chapters about objects (Chapter 12) and types (Chapter 13).

An operation is a special GAP function that bundles a set of functions, its methods.

All methods of an operation compute the same result. But each method is installed for specific types of arguments.

If an operation is called with a tuple of arguments, one of the applicable methods is selected and called.

Special cases of methods are partial methods, immediate methods, and logical implications.

#### 78.1 Operations and Methods

Operations are functions in the category `IsOperation` (78.1-1).

So on the one hand, operations are GAP functions, that is, they can be applied to arguments and return a result or cause a side-effect.

On the other hand, operations are more. Namely, an operation corresponds to a set of GAP functions, called the methods of the operation.

Each call of an operation causes a suitable method to be selected and then called. The choice of which method to select is made according to the types of the arguments, the underlying mechanism is described in the following sections.

Examples of operations are the binary infix operators `=`, `+` etc., and `PrintObj` (6.3-5) is the operation that is called for each argument of `Print` (6.3-4).

Also all attributes and properties are operations. Each attribute has a special method which is called if the attribute value is already stored; this method of course simply returns this value.

The setter of an attribute is called automatically if an attribute value has been computed. Attribute setters are operations, too. They have a default method that ignores the request to store the value. Depending on the type of the object, there may be another method to store the value in a suitable way, and then set the attribute tester for the object to `true`.

##### 78.1-1 IsOperation

`‣ IsOperation`( obj ) | ( category )

is the category of operations. Every operation is a function, but not vice versa.

    gap> MinimalPolynomial;
    <Operation "MinimalPolynomial">
    gap> IsOperation(MinimalPolynomial);
    true
    gap> IsFunction(MinimalPolynomial);
    true
    gap> Factorial;
    function( n ) ... end
    gap> IsOperation(Factorial);
    false

##### 78.1-2 TypeOfOperation

`‣ TypeOfOperation`( object ) | ( function )

returns a string from the list `[ "Attribute", "Operation", "Property", "Category", "Representation", "Filter", "Setter"]` reflecting which type of operation op is.

(see 13.3, 13.4, 13.5, 13.6, 13.7, 13.8)

##### 78.1-3 ShowDeclarationsOfOperation

`‣ ShowDeclarationsOfOperation`( oper ) | ( function )

Displays information about all declarations of the operation oper, including the location of each declaration and the argument filters.

    gap> ShowDeclarationsOfOperation(IsFinite);
    Available declarations for operation <Property "IsFinite">:
      1: GAPROOT/lib/coll.gd:1451 with 1 argument, and filters [ IsListOrCollection ]
      2: GAPROOT/lib/float.gd:212 with 1 argument, and filters [ IsFloat ]
      3: GAPROOT/lib/ctbl.gd:1195 with 1 argument, and filters [ IsNearlyCharacterTable ]

##### 78.1-4 NewOperation

`‣ NewOperation`( name, args-filts ) | ( function )

`NewOperation` returns an operation opr with name name. The list args-filts describes requirements about the arguments of opr, namely the number of arguments must be equal to the length of args-filts, and the i-th argument must lie in the filter args-filts[i].

Each method that is installed for opr via `InstallMethod` (78.3-1) must require that the i-th argument lies in the filter args-filts[i].

One can install methods for other argument tuples via `InstallOtherMethod` (78.3-2), this way it is also possible to install methods for a different number of arguments than the length of args-filts.

##### 78.1-5 DeclareOperation

`‣ DeclareOperation`( name, filters ) | ( function )

does the same as `NewOperation` (78.1-4) and then binds the new operation to the global variable name. The variable must previously be writable, and is made read-only by this function.

##### 78.1-6 Tag Based Operations

`‣ NewTagBasedOperation`( name, requirements ) | ( function )

`‣ DeclareTagBasedOperation`( name, requirements ) | ( function )

`‣ InstallTagBasedMethod`( oper[, tag], meth ) | ( function )

`NewTagBasedOperation` returns an operation with name name that is declared as tag based w.r.t. the list requirements of filters for its arguments. If an operation with name name exists already before the call then this operation is returned, otherwise a new operation gets created.

`DeclareTagBasedOperation` does the same and additionally binds the returned operation to the global variable name if the operation is new.

Declaring the operation oper as tag based w.r.t. requirements means that `InstallTagBasedMethod` can be used to install the method meth for oper, a function whose arguments satisfy requirements, with the following meaning.

- The method meth is applicable if the first argument of the call to oper is identical (in the sense of `IsIdenticalObj` (12.5-1)) with the tag tag that has been specified in the `InstallTagBasedMethod` call.

- If none of the tag based methods for oper has a tag that is identical with the first argument of the call to oper and if there is a tag based method for oper for which no tag was specified then this method is applicable.

Thus at most one tag based method for oper is applicable, and if a method without tag has been installed then it serves as the default method. This is in contrast to the situation with constructors (see 78.2) where the first argument is a filter that is used as a tag, but several methods can be applicable in a call to a constructor and one cannot define a default method for it.

Typical use cases for tag based operations are operations that shall create objects in particular internal representations; the filters that define these representations are then used as the first argument, and one wants that either the unique method that belongs to this filter or a default method is called.

Currently it is possible to declare an operation as tag based only for one list of requirements.

Installing methods with `InstallMethod` (78.3-1) for a tag based operation is possible. However, installing such methods with the same requirements as the ones for the tag based methods will have no effect because the handling of tag based methods gets installed with `InstallEarlyMethod` (78.3-3) and thus has higher priority.

#### 78.2 Constructors

Constructors are a special type of operation used to make new objects. The key difference compared to regular operations is that method selection works slightly differently for them: The first argument in a call to a constructor must always be a filter 13.2. The result of a method is expected to lie in that filter. Moreover, while normally method selection matches on the type of each argument, for a constructor the first argument is treated differently: instead of matching its type, the argument itself (which is a filter) must be a subset of the filter specified by the method which is being tested for match. In other words, the argument filter must imply the method filter.

Also, method ranking works differently: instead of the sum of the ranks of the types of all arguments, only the rank of the filter given as first argument is considered; and for it, the normal ranking order is reversed. This ensures that if multiple constructor methods match, the most general method is selected.

    gap> DeclareConstructor("XCons",[IsMagma,IsInt]);
    gap> InstallMethod(XCons, [IsGroup, IsInt], function(t,x) return CyclicGroup(x); end);
    gap> InstallMethod(XCons, [IsPermGroup, IsInt], function(t,x) return SymmetricGroup(x); end);
    gap> InstallMethod(XCons, [IsSemigroup, IsInt], function(t,x) return FullTransformationMonoid(x); end);
    gap> XCons(IsGroup,3);
    <pc group of size 3 with 1 generator>
    gap> XCons(IsPermGroup,3);
    Sym( [ 1 .. 3 ] )
    gap> XCons(IsSemigroup,4);
    <full transformation monoid of degree 4>
    gap> # if multiple methods match, the most general is selected:
    gap> XCons(IsMagma,3);
    <full transformation monoid of degree 3>

The example above shows some basic examples (usually a constructor will produce isomorphic objects in different representations, not different objects as in this case).

If no method has been installed which guarantees to produce a suitable objecty, a "No Method Found" error will be returned.

    gap> XCons(IsFullTransformationMonoid,4);
    Error, no method found! For debugging hints type ?Recovery from NoMethodFound
    Error, no 1st choice method found for `XCons' on 2 arguments
    called from read-eval loop at *stdin*:8
    type 'quit;' to quit to outer loop
    brk> quit;
    gap> XCons(IsNilpotentGroup,4);
    Error, no method found! For debugging hints type ?Recovery from NoMethodFound
    Error, no 1st choice method found for `XCons' on 2 arguments
    called from read-eval loop at *stdin*:8
    type 'quit;' to quit to outer loop
    brk>

Note that in both these cases there are methods that actually produce results of the required types, but they have not been installed with this information, so are not selected.

##### 78.2-1 NewConstructor

`‣ NewConstructor`( name, args-filts ) | ( function )

`NewConstructor` returns a constructor cons with name name. The list args-filts describes requirements about the arguments of cons. Namely the number of arguments must be equal to the length of args-filts, and the i-th argument must lie in the filter args-filts[i] for i ≠ 1. A constructor expects the first argument to be a filter instead of an object and it must be a subset of the filter args-filts[1].

Each method that is installed for cons via `InstallMethod` (78.3-1) must require that the i-th argument lies in the filter args-filts[i] for i ≠ 1. Its first argument is a filter and must be a subset of the filter args-filts[1].

One can install methods for other argument tuples via `InstallOtherMethod` (78.3-2), this way it is also possible to install methods for a different number of arguments than the length of args-filts.

Note that the method selection for constructors works slightly differently than for usual operations. As stated above, applicabilty to the first argument in an argument tuple is tested by determining whether the argument-filter is a subset of args-filts[1].

The rank of a method installed for a constructor is determined solely by args-filts[1] of the method. Instead of taking the sum of the ranks of filters involved in its args-filts[1], the sum of -1 times these values is taken. The result is added to the number val used in the call of `InstallMethod` (78.3-1).

This has the following effects on the method selection for constructors. If cons is called with an argument tuple whose first argument is the filter filt, any method whose first argument is more specific than filt is applicable (if its other args-filts also match). Then the method with the most general filter args-filts[1] is chosen, since the rank is computed by taking -1 times the ranks of the involved filters. Thus, a constructor is chosen which returns an object in filt using as few extra filters as possible, which presumably is both more flexible to use and easier to construct.

The following example showcases this behaviour. Note that the argument filter is only used for method dispatch.

    DeclareFilter( "IsMyObj" );
    DeclareFilter( "IsMyFilter" );
    DeclareFilter( "IsMyOtherFilter" );
    BindGlobal( "MyFamily", NewFamily( "MyFamily" ) );

    DeclareConstructor( "NewMyObj", [ IsMyObj ] );

    InstallMethod( NewMyObj,
    [ IsMyObj ],
    function( filter )
        local type;
        Print("General constructor\n");
        type := NewType( MyFamily, IsMyObj );
        return Objectify( type, [] );
    end );
    InstallMethod( NewMyObj,
    [ IsMyObj and IsMyFilter and IsMyOtherFilter ],
    function( filter )
        local type;
        Print("Special constructor\n");
        type := NewType( MyFamily, IsMyObj and IsMyFilter and IsMyOtherFilter );
        return Objectify( type, [] );
    end );

If only IsMyObj is given, both methods are applicable and the general constructor is called. If also IsMyFilter is given, only the special constructor is applicable.

    gap> a := NewMyObj( IsMyObj );;
    General constructor
    gap> IsMyOtherFilter(a);
    false
    gap> b := NewMyObj( IsMyObj and IsMyFilter );;
    Special constructor
    gap> IsMyOtherFilter(b);
    true
    gap> c := NewMyObj( IsMyObj and IsMyFilter and IsMyOtherFilter );;
    Special constructor
    gap> IsMyOtherFilter(c);
    true

##### 78.2-2 DeclareConstructor

`‣ DeclareConstructor`( name, filters ) | ( function )

does the same as `NewConstructor` (78.2-1) and then binds the result to the global variable name. The variable must previously be writable, and is made read-only by this function.

Note that for operations which are constructors special rules with respect to applicability and rank of the corresponding methods apply (see section `NewConstructor` (78.2-1)).

#### 78.3 Method Installation

In order to describe what it means to select a method of an operation, we must describe how the methods are connected to their operations.

For attributes and properties there is `InstallImmediateMethod` (78.7-1).

For declaring that a filter is implied by other filters there is `InstallTrueMethod` (78.8-1).

##### 78.3-1 InstallMethod

`‣ InstallMethod`( opr[, info][, famp], args-filts[, val], method ) | ( function )

installs a function method method for the operation opr; args-filts should be a list of requirements for the arguments, each entry being a filter; if supplied info should be a short but informative string that describes for what situation the method is installed, famp should be a function to be applied to the families of the arguments. val should be an integer that measures the priority of the method, or a function of no arguments which should return such an integer and will be called each time method order is being recalculated (see `InstallTrueMethod` (78.8-1)).

The default values for info, famp, and val are the empty string, the function `ReturnTrue` (5.4-1), and the integer zero, respectively.

The exact meaning of the arguments famp, args-filts, and val is explained in Section 78.4.

opr expects its methods to require certain filters for their arguments. For example, the argument of a method for the operation `Zero` (31.10-3) must be in the category `IsAdditiveElementWithZero` (31.14-5). It is not possible to use `InstallMethod` to install a method for which the entries of args-filts do not imply the respective requirements of the operation opr. If one wants to override this restriction, one has to use `InstallOtherMethod` (78.3-2) instead.

##### 78.3-2 InstallOtherMethod

`‣ InstallOtherMethod`( opr[, info][, famp], args-filts[, val], method ) | ( function )

installs a function method method for the operation opr, in the same way as for `InstallMethod` (78.3-1), but without the restriction that the number of arguments must match a declaration of opr and without the restriction that args-filts imply the respective requirements of the operation opr.

##### 78.3-3 InstallEarlyMethod

`‣ InstallEarlyMethod`( opr, method ) | ( function )

installs a special "early" function method method for the operation opr. An early method is special in that it bypasses method dispatch, and is always the first method to be called when invoking the operation.

This can be used to avoid method selection overhead for certain special cases, i.e., as an optimization. Overall, we recommend to use this feature very sparingly, as it is tool with sharp edges: for example, any inputs that are handled by an early method can not be intercepted by a regular method, no matter how high its rank is; this can preclude other kinds of optimizations.

Also, unlike regular methods, no checks are performed on the arguments. Not even the required filters for the operation are tested, so early methods must be careful in validating their inputs. This also means that any operation can have at most one such early method for each arity (i.e., one early method taking 1 argument, one early method taking 2 arguments, etc.).

If an early method determines that it is not applicable, it can resume regular method dispatch by invoking `TryNextMethod` (78.5-1).

For an example application of early methods, they are used by `First` (21.20-21) to deal with internal lists, for which computing the exact type (needed for method selection) can be very expensive.

##### 78.3-4 InstallMethodWithRandomSource

`‣ InstallMethodWithRandomSource`( opr, info[, famp], args-filts[, val], method ) | ( function )

`‣ InstallOtherMethodWithRandomSource`( opr, info[, famp], args-filts[, val], method ) | ( function )

These functions are designed to simplify adding new methods for `Random` (30.7-1), `PseudoRandom` (30.7-2), and `Randomize` (26.6-4) to GAP which can be called both with, and without, a random source.

They accept the same arguments as `InstallMethod` (78.3-1) and `InstallOtherMethod` (78.3-2), with the extra requirement that the first member of args-filts must be `IsRandomSource` (14.7-1), and the info argument is compulsory and must begin 'for a random source and'.

This function then installs two methods: first it calls `InstallMethod` (78.3-1) (or `InstallOtherMethod` (78.3-2)) with unchanged arguments. Then it calls `InstallMethod` (78.3-1) (or `InstallOtherMethod` (78.3-2)) a second time to install another method which lacks the initial random source argument; this additional method simply invokes the original method, with `GlobalMersenneTwister` (14.7-4) added as first argument.

#### 78.4 Applicable Methods and Method Selection

A method installed as above is applicable for an arguments tuple if the following conditions are satisfied.

The number of arguments equals the length of the list args-filts, the i-th argument lies in the filter args-filts[i], and famp returns `true` when applied to the families of the arguments. The maximal number of arguments supported for methods is six, one gets an error message if one tries to install a method with at least seven arguments.

So args-filt describes conditions for each argument, and famp describes a relation between the arguments.

For unary operations such as attributes and properties, there is no such relation to postulate, famp is `ReturnTrue` (5.4-1) for these operations, a function that always returns `true`. For binary operations, the usual value of famp is `IsIdenticalObj` (12.5-1), which means that both arguments must lie in the same family.

Note that any properties which occur among the filters in the filter list will not be tested by the method selection if they are not yet known. (More exact: if prop is a property then the filter implicitly uses not prop but `Hasprop and prop`.) If this is desired you must explicitly enforce a test (see section 78.6) below.

If no method is applicable, the error message no method found is signaled.

Otherwise, the applicable method with highest rank is selected and then called. This rank is usually given by the sum of the ranks of the filters in the list args-filt, including involved filters. This value can be modified by the optional val argument used in the call of `InstallMethod` (78.3-1), as follows.

- If val is an integer then add this value to the rank computed from the filters.

- If val is a function with zero arguments then add the value returned by this function to the rank computed from the filters.

- If val is a list of the form `[ filters ]` or `[ filters, abs ]`, where `filters` is a list of filters and `abs`, if given, is an integer, then ignore the filters in args-filt for the rank computation, and instead take the sum of the filters in `filters` (including involved filters) plus `abs`.

So the argument val can be used to raise or lower the priority of a method relative to other methods for opr. The variant where val is a function can be useful if one wants to shift the rank of the method by the rank of certain filters; note that such ranks need not be constant during a GAP session, they can grow due to implications, see `InstallTrueMethod` (78.8-1). The variant where val is a list can be useful for example if one wants that certain filters that are involved in args-filt are required but shall not count for the rank of the method.

Note that for operations which are constructors special rules with respect to applicability and rank of the corresponding methods apply (see `NewConstructor` (78.2-1)).

Note that from the applicable methods an efficient one shall be selected. This is a method that needs only little time and storage for the computations.

It seems to be impossible for GAP to select an optimal method in all cases. The present ranking of methods is based on the assumption that a method installed for a special situation shall be preferred to a method installed for a more general situation.

For example, a method for computing a Sylow subgroup of a nilpotent group is expected to be more efficient than a method for arbitrary groups. So the more specific method will be selected if GAP knows that the group given as argument is nilpotent.

Of course there is no obvious way to decide between the efficiency of incommensurable methods. For example, take an operation with one method for permutation groups, another method for nilpotent groups, but no method for nilpotent permutation groups, and call this operation with a permutation group known to be nilpotent.

#### 78.5 Partial Methods

##### 78.5-1 TryNextMethod

`‣ TryNextMethod`( ) | ( function )

After a method has been selected and called, the method may recognize that it cannot compute the desired result, and give up by calling `TryNextMethod()`.

In effect, the execution of the method is terminated, and the method selection calls the next method that is applicable w.r.t. the original arguments. In other words, the applicable method is called that is subsequent to the one that called `TryNextMethod`, according to decreasing rank of the methods.

For example, since every finite group of odd order is solvable, one may install a method for the property `IsSolvableGroup` (39.15-6) that checks whether the size of the argument is an odd integer, returns `true` if so, and gives up otherwise.

Care is needed if a partial method might modify the type of one of its arguments, for example by computing an attribute or property. If this happens, and the type has really changed, then the method should not exit using `TryNextMethod()` but should call the operation again, as the new information in the type may cause some methods previously judged inapplicable to be applicable. For example, if the above method for `IsSolvableGroup` (39.15-6) actually computes the size, (rather than just examining a stored size), then it must take care to check whether the type of the group has changed.

#### 78.6 Redispatching

As mentioned above the method selection will not test unknown properties. In situations, in which algorithms are only known (or implemented) under certain conditions, however such a test might be actually desired.

One way to achieve this would be to install the method under weaker conditions and explicitly test the properties first, exiting via `TryNextMethod` (78.5-1) if some of them are not fulfilled. A problem of this approach however is that such methods then automatically are ranked lower and that the code does not look nice.

A much better way is to use redispatching: Before deciding that no method has been found one tests these properties and if they turn out to be true the method selection is started anew (and will then find a method).

This can be achieved via the following function:

##### 78.6-1 RedispatchOnCondition

`‣ RedispatchOnCondition`( oper[, info], fampred, reqs, cond, val ) | ( function )

This function installs a method for the operation oper under the conditions fampred and reqs which has absolute value val; that is, the value of the filters reqs is disregarded. cond is a list of filters. If not all the values of properties involved in these filters are already known for actual arguments of the method, they are explicitly tested and if they are fulfilled and stored after this test, the operation is dispatched again. Otherwise the method exits with `TryNextMethod` (78.5-1). If supplied, info should be a short but informative string that describes these conditions. This can be used to enforce tests like `IsFinite` (30.4-2) in situations when all existing methods require this property. The list cond may have unbound entries in which case the corresponding argument is ignored for further tests.

#### 78.7 Immediate Methods

Usually a method is called only if its operation has been called and if this method has been selected, see `InstallMethod` (78.3-1).

For attributes and properties, one can install also immediate methods.

##### 78.7-1 InstallImmediateMethod

`‣ InstallImmediateMethod`( opr[, info], filter, rank, method ) | ( function )

`InstallImmediateMethod` installs method as an immediate method for opr, which must be an attribute or a property, with requirement filter and rank rank (the rank can be omitted, in which case 0 is used as rank). The rank must be an integer value that measures the priority of method among the immediate methods for opr. If supplied, info should be a short but informative string that describes the situation in which the method is called.

An immediate method is called automatically as soon as the object lies in filter, provided that the value is not yet known. Afterwards the attribute setter is called in order to store the value, unless the method exits via `TryNextMethod` (78.5-1).

Note the difference to `InstallMethod` (78.3-1) that no family predicate occurs because opr expects only one argument, and that filter is not a list of requirements but the argument requirement itself.

Immediate methods are thought of as a possibility for objects to gain useful knowledge. They must not be used to force the storing of defining information in an object. In other words, GAP should work even if all immediate methods are completely disabled. Therefore, the call to `InstallImmediateMethod` installs method also as an ordinary method for opr with requirement filter.

Note that in such a case GAP executes a computation for which it was not explicitly asked by the user. So one should install only those methods as immediate methods that are extremely cheap. To emphasize this, immediate methods are also called zero cost methods. The time for their execution should really be approximately zero.

For example, the size of a permutation group can be computed very cheaply if a stabilizer chain of the group is known. So it is reasonable to install an immediate method for `Size` (30.4-6) with requirement `IsGroup and Tester( stab )`, where stab is the attribute corresponding to the stabilizer chain.

Another example would be the implementation of the conclusion that every finite group of prime power order is nilpotent. This could be done by installing an immediate method for the attribute `IsNilpotentGroup` (39.15-3) with requirement `IsGroup and Tester( Size )`. This method would then check whether the size is a finite prime power, return `true` in this case and otherwise call `TryNextMethod` (78.5-1). But this requires factoring of an integer, which cannot be guaranteed to be very cheap, so one should not install this method as an immediate method.

##### 78.7-2 IsNoImmediateMethodsObject

`‣ IsNoImmediateMethodsObject`( obj ) | ( filter )

If this filter is set immediate methods will be ignored for obj. This can be crucial for performance for objects like pcgs (see Section 45.1), of which many are created, which are collections, but for which all those immediate methods for `IsTrivial` (30.4-3) et cetera do not really make sense. Other examples of objects in `IsNoImmediateMethodsObject` are compressed vectors and matrices over small finite fields, see the sections 23.3 and 24.14.

#### 78.8 Logical Implications

##### 78.8-1 InstallTrueMethod

`‣ InstallTrueMethod`( newfil, filt ) | ( function )

It may happen that a filter newfil shall be implied by another filter filt, which is usually a meet of other properties, or the meet of some properties and some categories. Such a logical implication can be installed as an immediate method for newfil that requires filt and that always returns `true`. (This should not be mixed up with the methods installed via `InstallImmediateMethod` (78.7-1), which have to be called at runtime for the actual objects.)

`InstallTrueMethod` has the effect that newfil becomes an implied filter of filt, see 13.2.

For example, each cyclic group is abelian, each finite vector space is finite dimensional, and each division ring is integral. The first of these implications is installed as follows.

    InstallTrueMethod( IsCommutative, IsGroup and IsCyclic );

Contrary to the immediate methods installed with `InstallImmediateMethod` (78.7-1), logical implications cannot be switched off. This means that after the above implication has been installed, one can rely on the fact that every object in the filter `IsGroup and IsCyclic` whose type gets created after the installation of the implication will also be in the filter `IsCommutative` (35.4-9). In particular, it may happen that an object which existed already before the installation of the implication lies in `IsGroup and IsCyclic` but not in `IsCommutative` (35.4-9). Thus it is advisable to install all implications between filters before one starts creating (types of) objects lying in these filters.

Adding logical implications can change the rank of filters (see `RankFilter` (13.2-1)) and consequently the rank, and so choice of methods for operations (see 78.4). By default `InstallTrueMethod` adjusts the method selection data structures to take care of this, but this process can be time-consuming, so functions `SuspendMethodReordering` (78.8-2) and `ResumeMethodReordering` (78.8-2) are provided to allow control of this process.

##### 78.8-2 SuspendMethodReordering

`‣ SuspendMethodReordering`( ) | ( function )

`‣ ResumeMethodReordering`( ) | ( function )

`‣ ResetMethodReordering`( ) | ( function )

These functions control whether the method reordering process described in `InstallTrueMethod` (78.8-1) is invoked or not. Since this process can be comparatively time-consuming, it is usually suspended when a lot of implications are due to be installed, for instance when loading the library, or a package. This is done by calling `SuspendMethodReordering` once the installations are done, `ResumeMethodReordering` should be called. These pairs of calls can be nested. When the outermost pair is complete, method reordering takes place and is enabled in `InstallTrueMethod` (78.8-1) thereafter. `ResetMethodReordering` effectively exits all nested suspensions, resuming reordering immediately. This function is mainly provided for error recovery and similar purposes and is called on quitting from a break loop.

#### 78.9 Operations and Mathematical Terms

Usually an operation stands for a mathematical concept, and the name of the operation describes this uniquely. Examples are the property `IsFinite` (30.4-2) and the attribute `Size` (30.4-6). But there are cases where the same mathematical term is used to denote different concepts, for example `Degree` is defined for polynomials, group characters, and permutation actions, and `Rank` is defined for matrices, free modules, p-groups, and transitive permutation actions.

It is in principle possible to install methods for the operation `Rank` that are applicable to the different types of arguments, corresponding to the different contexts. But this is not the approach taken in the GAP library. Instead there are operations such as `RankMat` (24.7-1) for matrices and `DegreeOfCharacter` (72.8-4) (in fact these are attributes) which are installed as methods of the ambiguous operations `Rank` and `Degree`.

The idea is to distinguish between on the one hand different ways to compute the same thing (e.g. different methods for `\=` (31.11-1), `Size` (30.4-6), etc.), and on the other hand genuinely different things (such as the degree of a polynomial and a permutation action).

The former is the basic purpose of operations and attributes. The latter is provided as a user convenience where mathematical usage forces it on us and where no conflicts arise. In programming the library, we use the underlying mathematically precise operations or attributes, such as `RankMat` (24.7-1) and `RankAction` (41.10-3). These should be attributes if appropriate, and the only role of the operation `Rank` is to decide which attribute the user meant. That way, stored information is stored with full mathematical precision and is less likely to be retrieved for a wrong purpose later.

One word about possible conflicts. A typical example is the mathematical term centre, which is defined as { x ∈ M | a * x = x * a ∀ a ∈ M } for a magma M, and as { x ∈ L | l * x = 0 ∀ l ∈ L } for a Lie algebra L. Here it is not possible to introduce an operation `Centre` (35.4-5) that delegates to attributes `CentreOfMagma` and `CentreOfLieAlgebra`, depending on the type of the argument. This is because any Lie algebra in GAP is also a magma, so both `CentreOfMagma` and `CentreOfLieAlgebra` would be defined for a Lie algebra, with different meaning if the characteristic is two. So we cannot achieve that one operation in GAP corresponds to the mathematical term centre.

Ambiguous operations such as `Rank` are declared in the library file `lib/overload.g`.

[Top of Book] [Contents] [Previous Chapter] [Next Chapter]
Goto Chapter: Top 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 Bib Ind

generated by GAPDoc2HTML