[prg] 5 An Example -- Residue Class Rings

[Top] [Up] [Previous] [Next] [Index]

# 5 An Example -- Residue Class Rings

### Sections

1. A First Attempt to Implement Elements of Residue Class Rings
2. Why Proceed in a Different Way?
3. A Second Attempt to Implement Elements of Residue Class Rings
4. Compatibility of Residue Class Rings with Prime Fields
5. Further Improvements in Implementing Residue Class Rings

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 Z/nZ.

The first attempt is straightforward (see Section A First Attempt to Implement Elements of Residue Class Rings), it deals with the implementation of the necessary arithmetic operations. Section Why Proceed in a Different Way? 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 A Second Attempt to Implement Elements of Residue Class Rings shows how this can be done in our example, and Section Compatibility of Residue Class Rings with Prime Fields, the question of further compatibility of the new objects with known GAP objects is discussed. Finally, Section Further Improvements in Implementing Residue Class Rings gives some hints how to improve the implementation presented before.

## 5.1 A First Attempt to Implement Elements of Residue Class Rings

Suppose we want to do computations with elements of a ring Z/nZ, where n is a positive integer.

First we have to decide how to represent the element k + nZ 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 [ k1, n ] and [ k2, n ] (of course with same modulus n) will be [ k, n ] with k1 + k2 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`.

    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;

    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;

    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;

    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 ] ]

## 5.2 Why Proceed in a Different Way?

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 Z/4Z. 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 Z/4Z, 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` 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 `\*`). 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 `reclass_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.

## 5.3 A Second Attempt to Implement Elements of Residue Class Rings

Faced with the problem to implement elements of the rings Z/nZ, 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 Types of Objects in the Reference Manual, 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 Z/nZ into a family of their own. This means that for example elements of Z/3Z and Z/9Z 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 A First Attempt to Implement Elements of Residue Class Rings, 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 Declaration and Implementation Part) 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 Z/nZ, 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 Z/nZ lie. This is done as follows.

    DeclareCategory( "IsMyZmodnZObj", IsScalar );
    DeclareCategoryCollections( "IsMyZmodnZObj" );

So all elements in the rings Z/nZ will lie in the category `IsMyZmodnZObj`, which is a subcategory of `IsScalar`. 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` 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 second line of GAP code above declares the category `CategoryCollections( IsMyZmodnZObj )`, which will be needed later; it is important to create this category before collections of the objects in `IsMyZmodnZObj` arise.

Note that the only difference between `DeclareCategory` and `NewCategory` is that in a call to `DeclareCategory`, a variable corresponding to the first argument is set to the new category, and this variable is read-only (see Global Variables in the Library). The same holds for `DeclareRepresentation` and `NewRepresentation` etc.

There is no analogue of categories in the implementation in Section A First Attempt to Implement Elements of Residue Class Rings, 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 A First Attempt to Implement Elements of Residue Class Rings, 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 + nZ 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 Positional Objects).

    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 Declaration and Implementation Part), to create an element when family and residue are given.

    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 Declaration and Implementation Part).

The probably most interesting function is the one to construct a residue class.

    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 Z/nZ; 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 Z/nZ 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 Declaration and Implementation Part).

    DeclareGlobalFunction( "MyZmodnZ" );

    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 Component Objects).

We see that we can use `RingWithOneByGenerators` to construct a ring with one if we have the appropriate generators. The construction via `RingWithOneByGenerators` makes sure that `IsRingWithOne` (and `IsRing`) 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` with the arguments `Integers` 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` 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` to `true` and the value of the attribute `Size` 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`, which is called for each argument in an explicit call to `Print`. Another one is `ViewObj`, which is called in the read-eval-print loop for each object. `ViewObj` shall produce short and human readable information about the object in question, whereas `PrintObj` shall produce information that may be longer and is (if reasonable) readable by GAP. We cannot satisfy the latter requirement for a `PrintObj` 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` method. Since the default for `ViewObj` is to call `PrintObj`, and since no other `ViewObj` method is applicable to our elements, we need only a `PrintObj` method.

    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` (first argument), and we gave it a suitable information message (second argument), see ApplicableMethod and Tracing Methods 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` can be found in Method Installation.

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.

    InstallMethod( \=,
        "for two elements in Z/nZ (ModulusRep)",
        IsIdenticalObj,
        [ IsMyZmodnZObj and IsMyModulusRep, IsMyZmodnZObj and IsMyModulusRep ],
        function( x, y ) return x![1] = y![1]; end );

    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 Families in the Reference Manual). This argument of a method installation, if present, is a function that shall be applied to the families of the arguments. `IsIdenticalObj` 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 A First Attempt to Implement Elements of Residue Class Rings. 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 A First Attempt to Implement Elements of Residue Class Rings 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.

    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 );

    InstallMethod( ZeroOp,
        "for element in Z/nZ (ModulusRep)",
        [ IsMyZmodnZObj ],
        x -> MyZmodnZObj( FamilyObj( x ), 0 ) );

    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 `\+` allows us to use the infix operator `+` for residue classes. The method for `ZeroOp` is used when we call this operation or the attribute `Zero` explicitly, and `ZeroOp` it is also used when we ask for `0 *` rescl``, where rescl is a residue class.

(Note that `Zero` and `ZeroOp` 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` 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`. The same holds for `AdditiveInverse`, `One`, and `Inverse`.)

Similarly, `AdditiveInverseOp` 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 Z/nZ, 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.

    InstallMethod( \+,
        "for element in Z/nZ (ModulusRep) and integer",
        [ IsMyZmodnZObj and IsMyModulusRep, IsInt ],
        function( x, y )
        return MyZmodnZObj( FamilyObj( x ), x![1] + y );
        end );

    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` is called when we ask for ``rescl`^0`, and `InverseOp` is called when we ask for ``rescl`^-1`. Note that the method for `InverseOp` returns `fail` if the argument is not invertible.

    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 );

    InstallMethod( OneOp,
        "for element in Z/nZ (ModulusRep)",
        [ IsMyZmodnZObj ],
        elm -> MyZmodnZObj( FamilyObj( elm ), 1 ) );

    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 Applicable Methods and Method Selection).

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` 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` 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` methods for objects in this new representation compatibly with our definition, i.e., such that the result is independent of the representation.

    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`. We make the ring print itself as `Integers` mod the modulus, and then it is reasonable to allow a construction this way, which makes the `PrintObj` output of the ring GAP readable.

    InstallMethod( PrintObj,
        "for full collection Z/nZ",
        [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ],
        function( R )
        Print( "(Integers mod ",
               ElementsFamily( FamilyObj(R) )!.modulus, ")" );
        end );

    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 A First Attempt to Implement Elements of Residue Class Rings, installing methods for existing operations is usually not possible or at least not recommended. For example, installing the function `resclass_sum` defined in Section A First Attempt to Implement Elements of Residue Class Rings as a `\+` 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` that takes a list `[` k`,` n`]` and returns k would in principle be possible, since there is no `Int` 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` methods could be installed with the same right.

As mentioned in Section Why Proceed in a Different Way?, 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. So we can also construct 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 );
    [ [ [ ( 8 mod 16 ), ( 5 mod 16 ) ], [ ( 11 mod 16 ), ( 7 mod 16 ) ] ] ]
    gap> Order( gens[1] );
    3

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 );
    <group with 1 generators>
    1
    gap> g:= Group( 3*x );  Size( g );
    <group with 1 generators>
    4

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.

    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 Z/nZ, 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 Z/nZ.

    InstallMethod( Random,
        "for full collection Z/nZ",
        [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ],
        R -> MyZmodnZObj( ElementsFamily( FamilyObj(R) ),
                        Random( [ 0 .. Size( R ) - 1 ] ) ) );

    InstallMethod( Size,
        "for full ring Z/nZ",
        [ CategoryCollections( IsMyZmodnZObj ) and IsWholeFamily ],
        R -> ElementsFamily( FamilyObj(R) )!.modulus );

    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` 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` (see GeneratorsPrimeResidues in the Reference Manual).

    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 Z/nZ is finite, and we could install a method that returns `true` when `IsFinite` is called with Z/nZ as argument. But we can do this more elegantly via installing a logical implication.

    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` is not called for it.

## 5.4 Compatibility of Residue Class Rings with Prime Fields

The above implementation of residue classes and residue class rings has at least two disadvantages. First, if p is a prime then the ring Z/pZ is in fact a field, but the return values of `MyZmodnZ` are never regarded as fields because they are not in the category `IsMagmaWithInversesIfNonzero`. 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 Z/pZ.

To be more precise, elements of finite fields in GAP lie in the category `IsFFE`, and there is already a representation, `IsInternalRep`, 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` (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.

    DeclareCategory( "IsMyZmodnZObj", IsScalar );

    DeclareCategory( "IsMyZmodnZObjNonprime", IsMyZmodnZObj );

    DeclareSynonym( "IsMyZmodpZObj", IsMyZmodnZObj and IsFFE );

    DeclareRepresentation( "IsMyModulusRep", IsPositionalObjectRep, [ 1 ] );

    DeclareGlobalFunction( "MyZmodnZObj" );

    DeclareGlobalFunction( "MyZmodnZ" );

As in the previous section, all (newly introduced) elements of rings Z/nZ lie in the category `IsMyZmodnZObj`. But now we introduce two subcategories, namely `IsMyZmodnZObjNonprime` for all elements in rings Z/nZ 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` of finite field elements.

It would be reasonable if also those internally represented elements in the category `IsFFE` 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`.

    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 );

    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` 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.

    InstallMethod( PrintObj,
        "for element in Z/nZ (ModulusRep)",
        [ IsMyZmodnZObjNonprime and IsMyModulusRep ],
        function( x )
        Print( "( ", x![1], " mod ", FamilyObj(x)!.modulus, " )" );
        end );

    InstallMethod( PrintObj,
        "for element in Z/pZ (ModulusRep)",
        [ IsMyZmodpZObj and IsMyModulusRep ],
        function( x )
        Print( "( ", x![1], " mod ", Characteristic(x), " )" );
        end );

    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.

    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 );

    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 Finite Fields in the Reference Manual. 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.

    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 );

    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 );

    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 );

    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 `\+`, `ZeroOp`, `AdditiveInverseOp`, `\-`, `\*`, and `OneOp` as in the previous section, without listing them below. Also the same `Int` method is installed for objects in `IsMyZmodnZObj`. Note that it is compatible with the definition of `Int` for finite field elements. And of course the same method for `\mod` is installed.

We have to be careful, however, with the methods for `InverseOp`, `\/`, and `\^`. These methods and the missing methods for arithmetic operations with one argument in `IsMyModulusRep` and the other in `IsInternalRep` are given below.

    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 );

    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 );

    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 );

    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 );

    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 );

    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` 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.

    InstallMethod( DegreeFFE,
        "for element in Z/pZ",
        [ IsMyZmodpZObj ],
        z -> 1 );

The methods for `Enumerator`, `Random`, `Size`, and `Units`, 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.

    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 );

    InstallMethod( Random,
        "for full ring Z/nZ",
        [ CategoryCollections( IsMyZmodnZObjNonprime ) and IsWholeFamily ],
        R -> MyZmodnZObj( ElementsFamily( FamilyObj( R ) ),
                        Random( [ 0 .. Size( R ) - 1 ] ) ) );

    InstallMethod( Size,
        "for full ring Z/nZ",
        [ CategoryCollections( IsMyZmodnZObjNonprime ) and IsWholeFamily ],
        R -> ElementsFamily( FamilyObj( R ) )!.modulus );

    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 );

    InstallTrueMethod( IsFinite,
        CategoryCollections( IsMyZmodnZObjNonprime ) and IsDomain );

## 5.5 Further Improvements in Implementing Residue Class Rings

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` methods that produce GAP readable output.

One can improve the `Units` 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` can be used, e. g., as input for the operation `SylowSubgroup`.

To make computations more efficient, one can install methods for `\-`, `\/`, and `\^`; 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` 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`. 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`, because the argument may have knowledge that is not correct for the result of the addition. One may think of the property `IsOne` 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 `\<` methods for pairs of objects in these categories.

[Top] [Up] [Previous] [Next] [Index]

GAP 4 manual
May 2002