In this chapter, we give an example how GAP can be extended by new data structures and new functionality. In order to focus on the issues of the implementation, the mathematics in the example chosen is trivial. Namely, we will discuss computations with elements of residue class rings ℤ / nℤ.
The first attempt is straightforward (see Section 81.1), it deals with the implementation of the necessary arithmetic operations. Section 81.2 deals with the question why it might be useful to use an approach that involves creating a new data structure and integrating the algorithms dealing with these new GAP objects into the system. Section 81.3 shows how this can be done in our example, and Section 81.4, the question of further compatibility of the new objects with known GAP objects is discussed. Finally, Section 81.5 gives some hints how to improve the implementation presented before.
Suppose we want to do computations with elements of a ring ℤ / nℤ, where n is a positive integer.
First we have to decide how to represent the element k + nℤ in GAP. If the modulus n is fixed then we can use the integer k. More precisely, we can use any integer k' such that k - k' is a multiple of n. If different moduli are likely to occur then using a list of the form [ k, n ], or a record of the form rec( residue := k, modulus := n ) is more appropriate. In the following, let us assume the list representation [ k, n ] is chosen. Moreover, we decide that the residue k in all such lists satisfies 0 ≤ k < n, i.e., the result of adding two residue classes represented by [ k_1, n ] and [ k_2, n ] (of course with same modulus n) will be [ k, n ] with k_1 + k_2 congruent to k modulo n and 0 ≤ k < n.
Now we can implement the arithmetic operations for residue classes. Note that the result of the mod operator is normalized as required. The division by a noninvertible residue class results in fail.
gap> resclass_sum := function( c1, c2 ) > if c1[2] <> c2[2] then Error( "different moduli" ); fi; > return [ ( c1[1] + c2[1] ) mod c1[2], c1[2] ]; > end;; gap> gap> resclass_diff := function( c1, c2 ) > if c1[2] <> c2[2] then Error( "different moduli" ); fi; > return [ ( c1[1] - c2[1] ) mod c1[2], c1[2] ]; > end;; gap> gap> resclass_prod := function( c1, c2 ) > if c1[2] <> c2[2] then Error( "different moduli" ); fi; > return [ ( c1[1] * c2[1] ) mod c1[2], c1[2] ]; > end;; gap> gap> resclass_quo := function( c1, c2 ) > local quo; > if c1[2] <> c2[2] then Error( "different moduli" ); fi; > quo:= QuotientMod( c1[1], c2[1], c1[2] ); > if quo <> fail then > quo:= [ quo, c1[2] ]; > fi; > return quo; > end;;
With these functions, we can in principle compute with residue classes.
gap> list:= List( [ 0 .. 3 ], k -> [ k, 4 ] ); [ [ 0, 4 ], [ 1, 4 ], [ 2, 4 ], [ 3, 4 ] ] gap> resclass_sum( list[2], list[4] ); [ 0, 4 ] gap> resclass_diff( list[1], list[2] ); [ 3, 4 ] gap> resclass_prod( list[2], list[4] ); [ 3, 4 ] gap> resclass_prod( list[3], list[4] ); [ 2, 4 ] gap> List( list, x -> resclass_quo( list[2], x ) ); [ fail, [ 1, 4 ], fail, [ 3, 4 ] ]
It depends on the computations we intended to do with residue classes whether or not the implementation described in the previous section is satisfactory for us.
Probably we are mainly interested in more complex data structures than the residue classes themselves, for example in matrix algebras or matrix groups over a ring such as ℤ / 4ℤ. For this, we need functions to add, multiply, invert etc. matrices of residue classes. Of course this is not a difficult task, but it requires to write additional GAP code.
And when we have implemented the arithmetic operations for matrices of residue classes, we might be interested in domain operations such as computing the order of a matrix group over ℤ / 4ℤ, a Sylow 2 subgroup, and so on. The problem is that a residue class represented as a pair [ k, n ] is not regarded as a group element by GAP. We have not yet discussed how a matrix of residue classes shall be represented, but if we choose the obvious representation of a list of lists of our residue classes then also this is not a valid group element in GAP. Hence we cannot apply the function Group (39.2-1) to create a group of residue classes or a group of matrices of residue classes. This is because GAP assumes that group elements can be multiplied via the infix operator * (equivalently, via the operation \* (31.12-1)). Note that in fact the multiplication of two lists [ k_1, n ], [ k_2, n ] is defined, but we have [ k_1, n ] * [ k_2, n ] = k_1 * k_2 + n * n, the standard scalar product of two row vectors of same length. That is, the multiplication with * is not compatible with the function resclass_prod introduced in the previous section. Similarly, ring elements are assumed to be added via the infix operator +; the addition of residue classes is not compatible with the available addition of row vectors.
What we have done in the previous section can be described as implementation of a standalone
arithmetic for residue classes. In order to use the machinery of the GAP library for creating higher level objects such as matrices, polynomials, or domains over residue class rings, we have to integrate
this implementation into the GAP library. The key step will be to create a new kind of GAP objects. This will be done in the following sections; there we assume that residue classes and residue class rings are not yet available in GAP; in fact they are available, and their implementation is very close to what is described here.
Faced with the problem to implement elements of the rings ℤ / nℤ, we must define the types of these elements as far as is necessary to distinguish them from other GAP objects.
As is described in Chapter 13, the type of an object comprises several aspects of information about this object; the family determines the relation of the object to other objects, the categories determine what operations the object admits, the representation determines how an object is actually represented, and the attributes describe knowledge about the object.
First of all, we must decide about the family of each residue class. A natural way to do this is to put the elements of each ring ℤ / nℤ into a family of their own. This means that for example elements of ℤ / 3ℤ and ℤ / 9ℤ lie in different families. So the only interesting relation between the families of two residue classes is equality; binary arithmetic operations with two residue classes will be admissible only if their families are equal. Note that in the naive approach in Section 81.1, we had to take care of different moduli by a check in each function; these checks may disappear in the new approach because of our choice of families.
Note that we do not need to tell GAP anything about the above decision concerning the families of the objects that we are going to implement, that is, the declaration part (see 79.11) of the little GAP package we are writing contains nothing about the distribution of the new objects into families. (The actual construction of a family happens in the function MyZmodnZ shown below.)
Second, we want to describe methods to add or multiply two elements in ℤ / nℤ, and these methods shall be not applicable to other GAP objects. The natural way to do this is to create a new category in which all elements of all rings ℤ / nℤ lie. This is done as follows.
gap> DeclareCategory( "IsMyZmodnZObj", IsScalar ); gap> cat:= CategoryCollections( IsMyZmodnZObj );; gap> cat:= CategoryCollections( cat );; gap> cat:= CategoryCollections( cat );;
So all elements in the rings ℤ / nℤ will lie in the category IsMyZmodnZObj, which is a subcategory of IsScalar (31.14-20). The latter means that one can add, subtract, multiply and divide two such elements that lie in the same family, with the obvious restriction that the second operand of a division must be invertible. (The name IsMyZmodnZObj is chosen because IsZmodnZObj (14.5-4) is already defined in GAP, for an implementation of residue classes that is very similar to the one developed in this manual chapter. Using this different name, one can simply enter the GAP code of this chapter into a GAP session, either interactively or by reading a file with this code, and experiment after each step whether the expected behaviour has been achieved, and what is still missing.)
The next lines of GAP code above create the categories CategoryCollections( IsMyZmodnZObj ) and two higher levels of collections categories of this, which will be needed later; it is important to create these categories before collections of the objects in IsMyZmodnZObj actually arise.
Note that the only difference between DeclareCategory (13.3-5) and NewCategory (13.3-4) is that in a call to DeclareCategory (13.3-5), a variable corresponding to the first argument is set to the new category, and this variable is read-only. The same holds for DeclareRepresentation (13.4-5) and NewRepresentation (13.4-4) etc.
There is no analogue of categories in the implementation in Section 81.1, since there it was not necessary to distinguish residue classes from other GAP objects. Note that the functions there assumed that their arguments were residue classes, and the user was responsible not to call them with other arguments. Thus an important aspect of types is to describe arguments of functions explicitly.
Third, we must decide about the representation of our objects. This is something we know already from Section 81.1, where we chose a list of length two. Here we may choose between two essentially different representations for the new GAP objects, namely as component object
(record-like) or positional object
(list-like). We decide to store the modulus of each residue class in its family, and to encode the element k + nℤ by the unique residue in the range [ 0 .. n-1 ] that is congruent to k modulo n, and the object itself is chosen to be a positional object with this residue at the first and only position (see 79.3).
gap> DeclareRepresentation("IsMyModulusRep", IsPositionalObjectRep, [1]);
The fourth ingredients of a type, attributes, are usually of minor importance for element objects. In particular, we do not need to introduce special attributes for residue classes.
Having defined what the new objects shall look like, we now declare a global function (see 79.11), to create an element when family and residue are given.
gap> DeclareGlobalFunction( "MyZmodnZObj" );
Now we have declared what we need, and we can start to implement the missing methods resp. functions; so the following command belongs to the implementation part of our package (see 79.11).
The probably most interesting function is the one to construct a residue class.
gap> InstallGlobalFunction( MyZmodnZObj, function( Fam, residue ) > return Objectify( NewType( Fam, IsMyZmodnZObj and IsMyModulusRep ), > [ residue mod Fam!.modulus ] ); > end );
Note that we normalize residue explicitly using mod; we assumed that the modulus is stored in Fam, so we must take care of this below. If Fam is a family of residue classes, and residue is an integer, MyZmodnZObj returns the corresponding object in the family Fam, which lies in the category IsMyZmodnZObj and in the representation IsMyModulusRep.
MyZmodnZObj needs an appropriate family as first argument, so let us see how to get our hands on this. Of course we could write a handy function to create such a family for given modulus, but we choose another way. In fact we do not really want to call MyZmodnZObj explicitly when we want to create residue classes. For example, if we want to enter a matrix of residues then usually we start with a matrix of corresponding integers, and it is more elegant to do the conversion via multiplying the matrix with the identity of the required ring ℤ / nℤ; this is also done for the conversion of integral matrices to finite field matrices. (Note that we will have to install a method for this.) So it is often sufficient to access this identity, for example via One( MyZmodnZ( n ) ), where MyZmodnZ returns a domain representing the ring ℤ / nℤ when called with the argument n. We decide that constructing this ring is a natural place where the creation of the family can be hidden, and implement the function. (Note that the declaration belongs to the declaration part, and the installation belongs to the implementation part, see 79.11).
gap> DeclareGlobalFunction( "MyZmodnZ" ); gap> gap> InstallGlobalFunction( MyZmodnZ, function( n ) > local F, R; > > if not IsPosInt( n ) then > Error( "<n> must be a positive integer" ); > fi; > > # Construct the family of element objects of our ring. > F:= NewFamily( Concatenation( "MyZmod", String( n ), "Z" ), > IsMyZmodnZObj ); > > # Install the data. > F!.modulus:= n; > > # Make the domain. > R:= RingWithOneByGenerators( [ MyZmodnZObj( F, 1 ) ] ); > SetIsWholeFamily( R, true ); > SetName( R, Concatenation( "(Integers mod ", String(n), ")" ) ); > > # Return the ring. > return R; > end );
Note that the modulus n is stored in the component modulus of the family, as is assumed by MyZmodnZ. Thus it is not necessary to store the modulus in each element. When storing n with the !. operator as value of the component modulus, we used that all families are in fact represented as component objects (see 79.2).
We see that we can use RingWithOneByGenerators (56.3-3) to construct a ring with one if we have the appropriate generators. The construction via RingWithOneByGenerators (56.3-3) makes sure that IsRingWithOne (56.3-1) (and IsRing (56.1-1)) is true for each output of MyZmodnZ. So the main problem is to create the identity element of the ring, which in our case suffices to generate the ring. In order to create this element via MyZmodnZObj, we have to construct its family first, at each call of MyZmodnZ.
Also note that we may enter known information about the ring. Here we store that it contains the whole family of elements; this is useful for example when we want to check the membership of an element in the ring, which can be decided from the type of the element if the ring contains its whole elements family. Giving a name to the ring causes that it will be printed via printing the name. (By the way: This name (Integers mod n) looks like a call to \mod (31.12-1) with the arguments Integers (14) and n; a construction of the ring via this call seems to be more natural than by calling MyZmodnZ; later we shall install a \mod (31.12-1) method in order to admit this construction.)
Now we can read the above code into GAP, and the following works already.
gap> R:= MyZmodnZ( 4 ); (Integers mod 4) gap> IsRing( R ); true gap> gens:= GeneratorsOfRingWithOne( R ); [ <object> ]
But of course this means just to ask for the information we have explicitly stored in the ring. Already the questions whether the ring is finite and how many elements it has, cannot be answered by GAP. Clearly we know the answers, and we could store them in the ring, by setting the value of the property IsFinite (30.4-2) to true and the value of the attribute Size (30.4-6) to n (the argument of the call to MyZmodnZ). If we do not want to do so then GAP could only try to find out the number of elements of the ring via forming the closure of the generators under addition and multiplication, but up to now, GAP does not know how to add or multiply two elements of our ring.
So we must install some methods for arithmetic and other operations if the elements are to behave as we want.
We start with a method for showing elements nicely on the screen. There are different operations for this purpose. One of them is PrintObj (6.3-5), which is called for each argument in an explicit call to Print (6.3-4). Another one is ViewObj (6.3-5), which is called in the read-eval-print loop for each object. ViewObj (6.3-5) shall produce short and human readable information about the object in question, whereas PrintObj (6.3-5) shall produce information that may be longer and is (if reasonable) readable by GAP. We cannot satisfy the latter requirement for a PrintObj (6.3-5) method because there is no way to make a family GAP readable. So we decide to display the expression ( k mod n ) for an object that is given by the residue k and the modulus n, which would be fine as a ViewObj (6.3-5) method. Since the default for ViewObj (6.3-5) is to call PrintObj (6.3-5), and since no other ViewObj (6.3-5) method is applicable to our elements, we need only a PrintObj (6.3-5) method.
gap> InstallMethod( PrintObj, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj and IsMyModulusRep ], > function( x ) > Print( "( ", x![1], " mod ", FamilyObj(x)!.modulus, " )" ); > end );
So we installed a method for the operation PrintObj (6.3-5) (first argument), and we gave it a suitable information message (second argument), see 7.2-1 and 7.3 for applications of this information string. The third argument tells GAP that the method is applicable for objects that lie in the category IsMyZmodnZObj and in the representation IsMyModulusRep. and the fourth argument is the method itself. More details about InstallMethod (78.3-1) can be found in 78.3.
Note that the requirement IsMyModulusRep for the argument x allows us to access the residue as x![1]. Since the family of x has the component modulus bound if it is constructed by MyZmodnZ, we may access this component. We check whether the method installation has some effect.
gap> gens; [ ( 1 mod 4 ) ]
Next we install methods for the comparison operations. Note that we can assume that the residues in the representation chosen are normalized.
gap> InstallMethod( \=, > "for two elements in Z/nZ (ModulusRep)", > IsIdenticalObj, > [IsMyZmodnZObj and IsMyModulusRep, IsMyZmodnZObj and IsMyModulusRep], > function( x, y ) return x![1] = y![1]; end ); gap> gap> InstallMethod( \<, > "for two elements in Z/nZ (ModulusRep)", > IsIdenticalObj, > [IsMyZmodnZObj and IsMyModulusRep, IsMyZmodnZObj and IsMyModulusRep], > function( x, y ) return x![1] < y![1]; end );
The third argument used in these installations specifies the required relation between the families of the arguments (see 13.1). This argument of a method installation, if present, is a function that shall be applied to the families of the arguments. IsIdenticalObj (12.5-1) means that the methods are applicable only if both arguments lie in the same family. (In installations for unary methods, obviously no relation is required, so this argument is left out there.)
Up to now, we see no advantage of the new approach over the one in Section 81.1. For a residue class represented as [ k, n ], the way it is printed on the screen is sufficient, and equality and comparison of lists are good enough to define equality and comparison of residue classes if needed. But this is not the case in other situations. For example, if we would have decided that the residue k need not be normalized then we would have needed functions in Section 81.1 that compute whether two residue classes are equal, and which of two residue classes is regarded as larger than another. Note that we are free to define what larger
means for objects that are newly introduced.
Next we install methods for the arithmetic operations, first for the additive structure.
gap> InstallMethod( \+, > "for two elements in Z/nZ (ModulusRep)", > IsIdenticalObj, > [IsMyZmodnZObj and IsMyModulusRep, IsMyZmodnZObj and IsMyModulusRep], > function( x, y ) > return MyZmodnZObj( FamilyObj( x ), x![1] + y![1] ); > end ); gap> gap> InstallMethod( ZeroOp, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj ], > x -> MyZmodnZObj( FamilyObj( x ), 0 ) ); gap> gap> InstallMethod( AdditiveInverseOp, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj and IsMyModulusRep ], > x -> MyZmodnZObj( FamilyObj( x ), AdditiveInverse( x![1] ) ) );
Here the new approach starts to pay off. The method for the operation \+ (31.12-1) allows us to use the infix operator + for residue classes. The method for ZeroOp (31.10-3) is used when we call this operation or the attribute Zero (31.10-3) explicitly, and ZeroOp (31.10-3) it is also used when we ask for 0 * rescl, where rescl is a residue class.
(Note that Zero (31.10-3) and ZeroOp (31.10-3) are distinguished because 0 * obj is guaranteed to return a mutable result whenever a mutable version of this result exists in GAP –for example if obj is a matrix– whereas Zero (31.10-3) is an attribute and therefore returns immutable results; for our example there is no difference since the residue classes are always immutable, nevertheless we have to install the method for ZeroOp (31.10-3). The same holds for AdditiveInverse (31.10-9), One (31.10-2), and Inverse (31.10-8).)
Similarly, AdditiveInverseOp (31.10-9) can be either called directly or via the unary - operator; so we can compute the additive inverse of the residue class rescl as -rescl.
It is not necessary to install methods for subtraction, since this is handled via addition of the additive inverse of the second argument if no other method is installed.
Let us try what we can do with the methods that are available now.
gap> x:= gens[1]; y:= x + x; ( 1 mod 4 ) ( 2 mod 4 ) gap> 0 * x; -x; ( 0 mod 4 ) ( 3 mod 4 ) gap> y = -y; x = y; x < y; -x < y; true false true false
We might want to admit the addition of integers and elements in rings ℤ / nℤ, where an integer is implicitly identified with its residue modulo n. To achieve this, we install methods to add an integer to an object in IsMyZmodnZObj from the left and from the right.
gap> InstallMethod( \+, > "for element in Z/nZ (ModulusRep) and integer", > [ IsMyZmodnZObj and IsMyModulusRep, IsInt ], > function( x, y ) > return MyZmodnZObj( FamilyObj( x ), x![1] + y ); > end ); gap> gap> InstallMethod( \+, > "for integer and element in Z/nZ (ModulusRep)", > [ IsInt, IsMyZmodnZObj and IsMyModulusRep ], > function( x, y ) > return MyZmodnZObj( FamilyObj( y ), x + y![1] ); > end );
Now we can do also the following.
gap> 2 + x; 7 - x; y - 2; ( 3 mod 4 ) ( 2 mod 4 ) ( 0 mod 4 )
Similarly we install the methods dealing with the multiplicative structure. We need methods to multiply two of our objects, and to compute identity and inverse. The operation OneOp (31.10-2) is called when we ask for rescl^0, and InverseOp (31.10-8) is called when we ask for rescl^-1. Note that the method for InverseOp (31.10-8) returns fail if the argument is not invertible.
gap> InstallMethod( \*, > "for two elements in Z/nZ (ModulusRep)", > IsIdenticalObj, > [IsMyZmodnZObj and IsMyModulusRep, IsMyZmodnZObj and IsMyModulusRep], > function( x, y ) > return MyZmodnZObj( FamilyObj( x ), x![1] * y![1] ); > end ); gap> gap> InstallMethod( OneOp, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj ], > elm -> MyZmodnZObj( FamilyObj( elm ), 1 ) ); gap> gap> InstallMethod( InverseOp, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj and IsMyModulusRep ], > function( elm ) > local residue; > residue:= QuotientMod( 1, elm![1], FamilyObj( elm )!.modulus ); > if residue <> fail then > residue:= MyZmodnZObj( FamilyObj( elm ), residue ); > fi; > return residue; > end );
To be able to multiply our objects with integers, we need not (but we may, and we should if we are going for efficiency) install special methods. This is because in general, GAP interprets the multiplication of an integer and an additive object as abbreviation of successive additions, and there is one generic method for such a multiplication that uses only additions and –in the case of a negative integer– taking the additive inverse. Analogously, there is a generic method for powering by integers that uses only multiplications and taking the multiplicative inverse.
Note that we could also interpret the multiplication with an integer as a shorthand for the multiplication with the corresponding residue class. We are lucky that this interpretation is compatible with the one that is already available. If this would not be the case then of course we would get into trouble by installing a concurrent multiplication that computes something different from the multiplication that is already defined, since GAP does not guarantee which of the applicable methods is actually chosen (see 78.4).
Now we have implemented methods for the arithmetic operations for our elements, and the following calculations work.
gap> y:= 2 * x; z:= (-5) * x; ( 2 mod 4 ) ( 3 mod 4 ) gap> y * z; y * y; ( 2 mod 4 ) ( 0 mod 4 ) gap> y^-1; y^0; fail ( 1 mod 4 ) gap> z^-1; ( 3 mod 4 )
There are some other operations in GAP that we may want to accept our elements as arguments. An example is the operation Int (14.2-3) that returns, e.g., the integral part of a rational number or the integer corresponding to an element in a finite prime field. For our objects, we may define that Int (14.2-3) returns the normalized residue.
Note that we define this behaviour for elements but we implement it for objects in the representation IsMyModulusRep. This means that if someone implements another representation of residue classes then this person must be careful to implement Int (14.2-3) methods for objects in this new representation compatibly with our definition, i.e., such that the result is independent of the representation.
gap> InstallMethod( Int, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObj and IsMyModulusRep ], > z -> z![1] );
Another example of an operation for which we might want to install a method is \mod (31.12-1). We make the ring print itself as Integers (14) mod the modulus, and then it is reasonable to allow a construction this way, which makes the PrintObj (6.3-5) output of the ring GAP readable.
gap> InstallMethod( PrintObj, > "for full collection Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ], > function( R ) > Print( "(Integers mod ", > ElementsFamily( FamilyObj(R) )!.modulus, ")" ); > end ); gap> gap> InstallMethod( \mod, > "for `Integers', and a positive integer", > [ IsIntegers, IsPosRat and IsInt ], > function( Integers, n ) return MyZmodnZ( n ); end );
Let us try this.
gap> Int( y ); 2 gap> Integers mod 1789; (Integers mod 1789)
Probably it is not necessary to emphasize that with the approach of Section 81.1, installing methods for existing operations is usually not possible or at least not recommended. For example, installing the function resclass_sum defined in Section 81.1 as a \+ (31.12-1) method for adding two lists of length two (with integer entries) would not be compatible with the general definition of the addition of two lists of same length. Installing a method for the operation Int (14.2-3) that takes a list [ k, n ] and returns k would in principle be possible, since there is no Int (14.2-3) method for lists yet, but it is not sensible to do so because one can think of other interpretations of such a list where different Int (14.2-3) methods could be installed with the same right.
As mentioned in Section 81.2, one advantage of the new approach is that with the implementation we have up to now, automatically also matrices of residue classes can be treated.
gap> r:= Integers mod 16; (Integers mod 16) gap> x:= One( r ); ( 1 mod 16 ) gap> mat:= IdentityMat( 2 ) * x; [ [ ( 1 mod 16 ), ( 0 mod 16 ) ], [ ( 0 mod 16 ), ( 1 mod 16 ) ] ] gap> mat[1][2]:= x;; gap> mat; [ [ ( 1 mod 16 ), ( 1 mod 16 ) ], [ ( 0 mod 16 ), ( 1 mod 16 ) ] ] gap> Order( mat ); 16 gap> mat + mat; [ [ ( 2 mod 16 ), ( 2 mod 16 ) ], [ ( 0 mod 16 ), ( 2 mod 16 ) ] ] gap> last^4; [ [ ( 0 mod 16 ), ( 0 mod 16 ) ], [ ( 0 mod 16 ), ( 0 mod 16 ) ] ]
Such matrices, if they are invertible, are valid as group elements. One technical problem is that the default algorithm for inverting matrices may give up since Gaussian elimination need not be successful over rings containing zero divisors. Therefore we install a simpleminded inversion method that inverts an integer matrix.
gap> InstallMethod( InverseOp, > "for an ordinary matrix over a ring Z/nZ", > [ IsMatrix and IsOrdinaryMatrix > and CategoryCollections( CategoryCollections( IsMyZmodnZObj ) ) ], > function( mat ) > local one, modulus; > > one:= One( mat[1][1] ); > modulus:= FamilyObj( one )!.modulus; > mat:= InverseOp( List( mat, row -> List( row, Int ) ) ); > if mat <> fail then > mat:= ( mat mod modulus ) * one; > fi; > if not IsMatrix( mat ) then > mat:= fail; > fi; > return mat; > end );
Additionally we install a method for finding a domain that contains the matrix entries; this is used by some GAP library functions.
gap> InstallMethod( DefaultFieldOfMatrixGroup, > "for a matrix group over a ring Z/nZ", > [ IsMatrixGroup and CategoryCollections( CategoryCollections( > CategoryCollections( IsMyZmodnZObj ) ) ) ], > G -> RingWithOneByGenerators([ One( Representative( G )[1][1] ) ]));
Now we can deal with matrix groups over residue class rings.
gap> mat2:= IdentityMat( 2 ) * x;; gap> mat2[2][1]:= x;; gap> g:= Group( mat, mat2 );; gap> Size( g ); 3072 gap> Factors( last ); [ 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3 ] gap> syl3:= SylowSubgroup( g, 3 );; gap> gens:= GeneratorsOfGroup( syl3 ); [ [ [ ( 1 mod 16 ), ( 7 mod 16 ) ], [ ( 11 mod 16 ), ( 14 mod 16 ) ] ] ] gap> Order( gens[1] ); 3
It should be noted that this way more involved methods for matrix groups may not be available. For example, many questions about a finite matrix group can be delegated to an isomorphic permutation group via a so-called nice monomorphism
; this can be controlled by the filter IsHandledByNiceMonomorphism (40.5-1).
By the way, also groups of (invertible) residue classes can be formed, but this may be of minor interest.
gap> g:= Group( x );; Size( g ); #I default `IsGeneratorsOfMagmaWithInverses' method returns `true' for [ ( 1 mod 16 ) ] 1 gap> g:= Group( 3*x );; Size( g ); #I default `IsGeneratorsOfMagmaWithInverses' method returns `true' for [ ( 3 mod 16 ) ] 4
(The messages above tell that GAP does not know a method for deciding whether the given elements are valid group elements. We could add an appropriate IsGeneratorsOfMagmaWithInverses method if we would want.)
Having done enough for the elements, we may install some more methods for the rings if we want to use them as arguments. These rings are finite, and there are many generic methods that will work if they are able to compute the list of elements of the ring, so we install a method for this.
gap> InstallMethod( Enumerator, > "for full collection Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ], > function( R ) > local F; > F:= ElementsFamily( FamilyObj(R) ); > return List( [ 0 .. Size( R ) - 1 ], x -> MyZmodnZObj( F, x ) ); > end );
Note that this method is applicable only to full rings ℤ / nℤ, for proper subrings it would return a wrong result. Furthermore, it is not required that the argument is a ring; in fact this method is applicable also to the additive group formed by all elements in the family, provided that it knows to contain the whole family.
Analogously, we install methods to compute the size, a random element, and the units of full rings ℤ / nℤ.
gap> InstallMethod( Random, > "for full collection Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ], > R -> MyZmodnZObj( ElementsFamily( FamilyObj(R) ), > Random( 0, Size( R ) - 1 ) ) ); gap> gap> InstallMethod( Size, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ], > R -> ElementsFamily( FamilyObj(R) )!.modulus ); gap> gap> InstallMethod( Units, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) > and IsWholeFamily and IsRing ], > function( R ) > local F; > F:= ElementsFamily( FamilyObj( R ) ); > return List( PrimeResidues( Size(R) ), x -> MyZmodnZObj( F, x ) ); > end );
The Units (56.5-2) method has the disadvantage that the result is returned as a list (in fact this list is also strictly sorted). We could improve the implementation by returning the units as a group; if we do not want to take the full list of elements as generators, we can use the function GeneratorsPrimeResidues (15.2-4).
gap> InstallMethod( Units, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObj ) > and IsWholeFamily and IsRing ], > function( R ) > local G, gens; > > gens:= GeneratorsPrimeResidues( Size( R ) ).generators; > if not IsEmpty( gens ) and gens[ 1 ] = 1 then > gens:= gens{ [ 2 .. Length( gens ) ] }; > fi; > gens:= Flat( gens ) * One( R ); > return GroupByGenerators( gens, One( R ) ); > end );
Each ring ℤ / nℤ is finite, and we could install a method that returns true when IsFinite (30.4-2) is called with ℤ / nℤ as argument. But we can do this more elegantly via installing a logical implication.
gap> InstallTrueMethod( IsFinite, > CategoryCollections( IsMyZmodnZObj ) and IsDomain );
In effect, every domain that consists of elements in IsMyZmodnZObj will automatically store that it is finite, even if IsFinite (30.4-2) is not called for it.
The above implementation of residue classes and residue class rings has at least two disadvantages. First, if p is a prime then the ring ℤ / pℤ is in fact a field, but the return values of MyZmodnZ are never regarded as fields because they are not in the category IsMagmaWithInversesIfNonzero (35.1-3). Second, and this makes the example really interesting, there are already elements of finite prime fields implemented in GAP, and we may want to identify them with elements in ℤ / pℤ.
To be more precise, elements of finite fields in GAP lie in the category IsFFE (59.1-1), and there is already a representation, IsInternalRep (13.4-1), of these elements via discrete logarithms. The aim of this section is to make IsMyModulusRep an alternative representation of elements in finite prime fields.
Note that this is only one step towards the desired compatibility. Namely, after having a second representation of elements in finite prime fields, we may wish that the function GF (59.3-2) (which is the usual function to create finite fields in GAP) is able to return MyZmodnZ( p ) when GF( p ) is called for a prime p. Moreover, then we have to decide about a default representation of elements in GF( p ) for primes p for which both representations are available. Of course we can force the new representation by explicitly calling MyZmodnZ and MyZmodnZObj whenever we want, but it is not a priori clear in which situation which representation is preferable.
The same questions will occur when we want to implement a new representation for non-prime fields. The steps of this implementation will be the same as described in this chapter, and we will have to achieve compatibility with both the internal representation of elements in small finite fields and the representation IsMyModulusRep of elements in arbitrary prime fields.
But let us now turn back to the task of this section. We first adjust the setup of the declaration part of the previous section, and then repeat the installations with suitable modifications.
(We should start a new GAP session for that, otherwise GAP will complain that the objects to be declared are already bound; additionally, the methods installed above may be not compatible with the ones we want.)
gap> DeclareCategory( "IsMyZmodnZObj", IsScalar ); gap> gap> DeclareCategory( "IsMyZmodnZObjNonprime", IsMyZmodnZObj ); gap> gap> DeclareSynonym( "IsMyZmodpZObj", IsMyZmodnZObj and IsFFE ); gap> gap> DeclareRepresentation( "IsMyModulusRep", IsPositionalObjectRep, [ 1 ] ); gap> gap> DeclareGlobalFunction( "MyZmodnZObj" ); gap> gap> DeclareGlobalFunction( "MyZmodnZ" );
As in the previous section, all (newly introduced) elements of rings ℤ / nℤ lie in the category IsMyZmodnZObj. But now we introduce two subcategories, namely IsMyZmodnZObjNonprime for all elements in rings ℤ / nℤ where n is not a prime, and IsMyZmodpZObj for elements in finite prime fields. All objects in the latter are automatically known to lie in the category IsFFE (59.1-1) of finite field elements.
It would be reasonable if also those internally represented elements in the category IsFFE (59.1-1) that do in fact lie in a prime field would also lie in the category IsMyZmodnZObj (and thus in fact in IsMyZmodpZObj). But this cannot be achieved because internally represented finite field elements do in general not store whether they lie in a prime field.
As for the implementation part, again let us start with the definitions of MyZmodnZObj and MyZmodnZ.
gap> InstallGlobalFunction( MyZmodnZObj, function( Fam, residue ) > if IsFFEFamily( Fam ) then > return Objectify( NewType( Fam, IsMyZmodpZObj > and IsMyModulusRep ), > [ residue mod Characteristic( Fam ) ] ); > else > return Objectify( NewType( Fam, IsMyZmodnZObjNonprime > and IsMyModulusRep ), > [ residue mod Fam!.modulus ] ); > fi; > end ); gap> InstallGlobalFunction( MyZmodnZ, function( n ) > local F, R; > > if not ( IsInt( n ) and IsPosRat( n ) ) then > Error( "<n> must be a positive integer" ); > elif IsPrimeInt( n ) then > # Construct the family of element objects of our field. > F:= FFEFamily( n ); > # Make the domain. > R:= FieldOverItselfByGenerators( [ MyZmodnZObj( F, 1 ) ] ); > SetIsPrimeField( R, true ); > else > # Construct the family of element objects of our ring. > F:= NewFamily( Concatenation( "MyZmod", String( n ), "Z" ), > IsMyZmodnZObjNonprime ); > # Install the data. > F!.modulus:= n; > # Make the domain. > R:= RingWithOneByGenerators( [ MyZmodnZObj( F, 1 ) ] ); > SetIsWholeFamily( R, true ); > SetName( R, Concatenation( "(Integers mod ",String(n),")" ) ); > fi; > > # Return the ring resp. field. > return R; > end );
Note that the result of MyZmodnZ with a prime as argument is a field that does not contain the whole family of its elements, since all finite field elements of a fixed characteristic lie in the same family. Further note that we cannot expect a family of finite field elements to have a component modulus, so we use Characteristic (31.10-1) to get the modulus. Requiring that Fam!.modulus works also if Fam is a family of finite field elements would violate the rule that an extension of GAP should not force changes in existing code, in this case code dealing with families of finite field elements.
gap> InstallMethod( PrintObj, > "for element in Z/nZ (ModulusRep)", > [ IsMyZmodnZObjNonprime and IsMyModulusRep ], > function( x ) > Print( "( ", x![1], " mod ", FamilyObj(x)!.modulus, " )" ); > end ); gap> gap> InstallMethod( PrintObj, > "for element in Z/pZ (ModulusRep)", > [ IsMyZmodpZObj and IsMyModulusRep ], > function( x ) > Print( "( ", x![1], " mod ", Characteristic(x), " )" ); > end ); gap> gap> InstallMethod( \=, > "for two elements in Z/nZ (ModulusRep)", > IsIdenticalObj, > [ IsMyZmodnZObj and IsMyModulusRep, > IsMyZmodnZObj and IsMyModulusRep ], > function( x, y ) return x![1] = y![1]; end );
The above method to check equality is independent of whether the arguments have a prime or nonprime modulus, so we installed it for arguments in IsMyZmodnZObj. Now we install also methods to compare objects in IsMyZmodpZObj with the old
finite field elements.
gap> InstallMethod( \=, > "for element in Z/pZ (ModulusRep) and internal FFE", > IsIdenticalObj, > [ IsMyZmodpZObj and IsMyModulusRep, IsFFE and IsInternalRep ], > function( x, y ) > return DegreeFFE( y ) = 1 and x![1] = IntFFE( y ); > end ); gap> gap> InstallMethod( \=, > "for internal FFE and element in Z/pZ (ModulusRep)", > IsIdenticalObj, > [ IsFFE and IsInternalRep, IsMyZmodpZObj and IsMyModulusRep ], > function( x, y ) > return DegreeFFE( x ) = 1 and IntFFE( x ) = y![1]; > end );
The situation with the operation < is more difficult. Of course we are free to define the comparison of objects in IsMyZmodnZObjNonprime, but for the finite field elements, the comparison must be compatible with the predefined comparison of the old
finite field elements. The definition of the < comparison of internally represented finite field elements can be found in Chapter 59. In situations where the documentation does not provide the required information, one has to look it up in the GAP code; for example, the comparison in our case can be found in the appropriate source code file of the GAP kernel.
gap> InstallMethod( \<, > "for two elements in Z/nZ (ModulusRep, nonprime)", > IsIdenticalObj, > [ IsMyZmodnZObjNonprime and IsMyModulusRep, > IsMyZmodnZObjNonprime and IsMyModulusRep ], > function( x, y ) return x![1] < y![1]; end ); gap> gap> InstallMethod( \<, > "for two elements in Z/pZ (ModulusRep)", > IsIdenticalObj, > [ IsMyZmodpZObj and IsMyModulusRep, > IsMyZmodpZObj and IsMyModulusRep ], > function( x, y ) > local p, r; # characteristic and primitive root > if x![1] = 0 then > return y![1] <> 0; > elif y![1] = 0 then > return false; > else > p:= Characteristic( x ); > r:= PrimitiveRootMod( p ); > return LogMod( x![1], r, p ) < LogMod( y![1], r, p ); > fi; > end ); gap> gap> InstallMethod( \<, > "for element in Z/pZ (ModulusRep) and internal FFE", > IsIdenticalObj, > [ IsMyZmodpZObj and IsMyModulusRep, IsFFE and IsInternalRep ], > function( x, y ) > return x![1] * One( y ) < y; > end ); gap> gap> InstallMethod( \<, > "for internal FFE and element in Z/pZ (ModulusRep)", > IsIdenticalObj, > [ IsFFE and IsInternalRep, IsMyZmodpZObj and IsMyModulusRep ], > function( x, y ) > return x < y![1] * One( x ); > end );
Now we install the same methods for the arithmetic operations \+ (31.12-1), ZeroOp (31.10-3), AdditiveInverseOp (31.10-9), \-, \* (31.12-1), and OneOp (31.10-2) as in the previous section, without listing them below. Also the same Int (14.2-3) method is installed for objects in IsMyZmodnZObj. Note that it is compatible with the definition of Int (14.2-3) for finite field elements. And of course the same method for \mod (31.12-1) is installed.
We have to be careful, however, with the methods for InverseOp (31.10-8), \/ (31.12-1), and \^ (31.12-1). These methods and the missing methods for arithmetic operations with one argument in IsMyModulusRep and the other in IsInternalRep (13.4-1) are given below.
gap> InstallMethod( \+, > "for element in Z/pZ (ModulusRep) and internal FFE", > IsIdenticalObj, > [ IsMyZmodpZObj and IsMyModulusRep, IsFFE and IsInternalRep ], > function( x, y ) return x![1] + y; end ); gap> gap> InstallMethod( \+, > "for internal FFE and element in Z/pZ (ModulusRep)", > IsIdenticalObj, > [ IsFFE and IsInternalRep, IsMyZmodpZObj and IsMyModulusRep ], > function( x, y ) return x + y![1]; end ); gap> gap> InstallMethod( \*, > "for element in Z/pZ (ModulusRep) and internal FFE", > IsIdenticalObj, > [ IsMyZmodpZObj and IsMyModulusRep, IsFFE and IsInternalRep ], > function( x, y ) return x![1] * y; end ); gap> gap> InstallMethod( \*, > "for internal FFE and element in Z/pZ (ModulusRep)", > IsIdenticalObj, > [ IsFFE and IsInternalRep, IsMyZmodpZObj and IsMyModulusRep ], > function( x, y ) return x * y![1]; end ); gap> gap> InstallMethod( InverseOp, > "for element in Z/nZ (ModulusRep, nonprime)", > [ IsMyZmodnZObjNonprime and IsMyModulusRep ], > function( x ) > local residue; > residue:= QuotientMod( 1, x![1], FamilyObj(x)!.modulus ); > if residue <> fail then > residue:= MyZmodnZObj( FamilyObj(x), residue ); > fi; > return residue; > end ); gap> gap> InstallMethod( InverseOp, > "for element in Z/pZ (ModulusRep)", > [ IsMyZmodpZObj and IsMyModulusRep ], > function( x ) > local residue; > residue:= QuotientMod( 1, x![1], Characteristic( FamilyObj(x) ) ); > if residue <> fail then > residue:= MyZmodnZObj( FamilyObj(x), residue ); > fi; > return residue; > end );
The operation DegreeFFE (59.2-1) is defined for finite field elements, we need a method for objects in IsMyZmodpZObj. Note that we need not require IsMyModulusRep since no access to representation dependent data occurs.
gap> InstallMethod( DegreeFFE, > "for element in Z/pZ", > [ IsMyZmodpZObj ], > z -> 1 );
The methods for Enumerator (30.3-2), Random (30.7-1), Size (30.4-6), and Units (56.5-2), that we had installed in the previous section had all assumed that their argument contains the whole family of its elements. So these methods make sense only for the nonprime case. For the prime case, there are already methods for these operations with argument a field.
gap> InstallMethod( Enumerator, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObjNonprime ) and IsWholeFamily ], > function( R ) > local F; > F:= ElementsFamily( FamilyObj( R ) ); > return List( [ 0 .. Size( R ) - 1 ], x -> MyZmodnZObj( F, x ) ); > end ); gap> gap> InstallMethod( Random, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObjNonprime ) and IsWholeFamily ], > R -> MyZmodnZObj( ElementsFamily( FamilyObj( R ) ), > Random( 0, Size( R ) - 1 ) ) ); gap> gap> InstallMethod( Size, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObjNonprime ) and IsWholeFamily ], > R -> ElementsFamily( FamilyObj( R ) )!.modulus ); gap> gap> InstallMethod( Units, > "for full ring Z/nZ", > [ CategoryCollections( IsMyZmodnZObjNonprime ) > and IsWholeFamily and IsRing ], > function( R ) > local G, gens; > > gens:= GeneratorsPrimeResidues( Size( R ) ).generators; > if not IsEmpty( gens ) and gens[ 1 ] = 1 then > gens:= gens{ [ 2 .. Length( gens ) ] }; > fi; > gens:= Flat( gens ) * One( R ); > return GroupByGenerators( gens, One( R ) ); > end ); gap> gap> InstallTrueMethod( IsFinite, > CategoryCollections( IsMyZmodnZObjNonprime ) and IsDomain );
There are of course many possibilities to improve the implementation.
With the setup as described above, subsequent calls MyZmodnZ( n ) with the same n yield incompatible rings in the sense that elements of one ring cannot be added to elements of an other one. The solution for this problem is to keep a global list of all results of MyZmodnZ in the current GAP session, and to return the stored values whenever possible. Note that this approach would admit PrintObj (6.3-5) methods that produce GAP readable output.
One can improve the Units (56.5-2) method for the full ring in such a way that a group is returned and not only a list of its elements; then the result of Units (56.5-2) can be used, e. g., as input for the operation SylowSubgroup (39.13-1).
To make computations more efficient, one can install methods for \-, \/ (31.12-1), and \^ (31.12-1); one reason for doing so may be that this avoids the unnecessary construction of the additive or multiplicative inverse, or of intermediate powers.
InstallMethod( \-, "two elements in Z/nZ (ModulusRep)", ... ); InstallMethod( \-, "Z/nZ-obj. (ModulusRep) and integer", ... ); InstallMethod( \-, "integer and Z/nZ-obj. (ModulusRep)", ... ); InstallMethod( \-, "Z/pZ-obj. (ModulusRep) and internal FFE", ... ); InstallMethod( \-, "internal FFE and Z/pZ-obj. (ModulusRep)", ... ); InstallMethod( \*, "Z/nZ-obj. (ModulusRep) and integer", ... ); InstallMethod( \*, "integer and Z/nZ-obj. (ModulusRep)", ... ); InstallMethod( \/, "two Z/nZ-objs. (ModulusRep, nonprime)", ... ); InstallMethod( \/, "two Z/pZ-objs. (ModulusRep)", ... ); InstallMethod( \/, "Z/nZ-obj. (ModulusRep) and integer", ... ); InstallMethod( \/, "integer and Z/nZ-obj. (ModulusRep)", ... ); InstallMethod( \/, "Z/pZ-obj. (ModulusRep) and internal FFE", ... ); InstallMethod( \/, "internal FFE and Z/pZ-obj. (ModulusRep)", ... ); InstallMethod( \^, "Z/nZ-obj. (ModulusRep, nonprime) & int.", ... ); InstallMethod( \^, "Z/pZ-obj. (ModulusRep), and integer", ... );
The call to NewType (13.9-3) in MyZmodnZObj can be avoided by storing the required type, e.g., in the family. But note that it is not admissible to take the type of an existing object as first argument of Objectify (79.1-1). For example, suppose two objects in IsMyZmodnZObj shall be added. Then we must not use the type of one of the arguments in a call of Objectify (79.1-1), because the argument may have knowledge that is not correct for the result of the addition. One may think of the property IsOne (31.10-5) that may hold for both arguments but certainly not for their sum.
For comparing two objects in IsMyZmodpZObj via
, we had to install a quite expensive method because of the compatibility with the comparison of finite field elements that did already exist. In fact GAP supports finite fields with elements represented via discrete logarithms only up to a given size. So in principle we have the freedom to define a cheaper comparison via <
for objects in <IsMyZmodpZObj if the modulus is large enough. This is possible by introducing two categories IsMyZmodpZObjSmall and IsMyZmodpZObjLarge, which are subcategories of IsMyZmodpZObj, and to install different \< (31.11-1) methods for pairs of objects in these categories.
generated by GAPDoc2HTML