%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%W  xtndxmpl.tex              GAP manual                    Thomas Breuer
%%
%H  @(#)$Id: xtndxmpl.tex,v 4.19 2002/10/11 08:00:00 gap Exp $
%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Chapter{An Example -- 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/n\Z$.

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.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Section{A First Attempt to Implement Elements of Residue Class Rings}

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

First we have to decide how to represent the element $k + n\Z$ in {\GAP}.
If the modulus $n$ is fixed then we can use the integer $k$.
More precisely, we can use any integer $k^{\prime}$
such that $k - k^{\prime}$ 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 \le 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 \le 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'.
\beginexample
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;;
\endexample
With these functions, we can in principle compute with residue classes.
\beginexample
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 ] ]
\endexample


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Section{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/4\Z$.
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/4\Z$,
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.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Section{A Second Attempt to Implement Elements of Residue Class Rings}

Faced with the problem to implement elements of the rings $\Z/n\Z$,
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~"ref: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/n\Z$
into a family of their own.
This means that for example elements of $\Z/3\Z$ and $\Z/9\Z$ 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/n\Z$,
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/n\Z$ lie.
This is done as follows.

\beginexample
gap> DeclareCategory( "IsMyZmodnZObj", IsScalar );
gap> cat:= CategoryCollections( IsMyZmodnZObj );;
gap> cat:= CategoryCollections( cat );;
gap> cat:= CategoryCollections( cat );;
\endexample

So all elements in the rings $\Z/n\Z$ 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 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' 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 + n\Z$ 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").

\beginexample
gap> DeclareRepresentation( "IsMyModulusRep", IsPositionalObjectRep, [ 1 ] );
\endexample

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.

\beginexample
gap> DeclareGlobalFunction( "MyZmodnZObj" );
\endexample

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.

\beginexample
gap> InstallGlobalFunction( MyZmodnZObj, function( Fam, residue )
>    return Objectify( NewType( Fam, IsMyZmodnZObj and IsMyModulusRep ),
>                      [ residue mod Fam!.modulus ] );
> end );
\endexample

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/n\Z$;
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/n\Z$
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").

\beginexample
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 );
\endexample

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.

\beginexample
gap> R:= MyZmodnZ( 4 );
(Integers mod 4)
gap> IsRing( R );
true
gap> gens:= GeneratorsOfRingWithOne( R );
[ <object> ]
\endexample

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.

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

So we installed a method for the operation `PrintObj' (first argument),
and we gave it a suitable information message (second argument),
see~"ref:ApplicableMethod" and~"ref: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.

\beginexample
gap> gens;
[ ( 1 mod 4 ) ]
\endexample

Next we install methods for the comparison operations.
Note that we can assume that the residues in the representation chosen
are normalized.

\beginexample
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 );
\endexample

The third argument used in these installations specifies the required
relation between the families of the arguments
(see~"ref: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.

\beginexample
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] ) ) );
\endexample

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.

\beginexample
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
\endexample

We might want to admit the addition of integers and elements in
rings $\Z/n\Z$, 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.

\beginexample
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 );
\endexample

Now we can do also the following.

\beginexample
gap> 2 + x;  7 - x;  y - 2;
( 3 mod 4 )
( 2 mod 4 )
( 0 mod 4 )
\endexample

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.

\beginexample
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 );
\endexample

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.

\beginexample
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 )
\endexample

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.

\beginexample
gap> InstallMethod( Int,
>    "for element in Z/nZ (ModulusRep)",
>    [ IsMyZmodnZObj and IsMyModulusRep ],
>    z -> z![1] );
\endexample

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.

\beginexample
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 );
\endexample

Let us try this.

\beginexample
gap> Int( y );
2
gap> Integers mod 1789;
(Integers mod 1789)
\endexample

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.
\beginexample
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 ) ] ]
\endexample

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.

\beginexample
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 );
\endexample

Additionally we install a method for finding a domain that contains the
matrix entries; this is used by some {\GAP} library functions.

\beginexample
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] ) ] ) );
\endexample

Now we can deal with matrix groups over residue class rings.

\beginexample
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
\endexample

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'
(see~"ref:IsHandledByNiceMonomorphism" in the {\GAP} Reference Manual).

By the way, also groups of (invertible) residue classes can be formed,
but this may be of minor interest.
\beginexample
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
\endexample

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

\beginexample
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 );
\endexample

Note that this method is applicable only to full rings $\Z/n\Z$,
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/n\Z$.

\beginexample
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 );
\endexample

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~"ref:GeneratorsPrimeResidues" in the Reference Manual).

\beginexample
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 );
\endexample

Each ring $\Z/n\Z$ is finite,
and we could install a method that returns `true' when `IsFinite' is
called with $\Z/n\Z$ as argument.
But we can do this more elegantly via installing a *logical implication*.

\beginexample
gap> InstallTrueMethod( IsFinite,
>    CategoryCollections( IsMyZmodnZObj ) and IsDomain );
\endexample

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.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Section{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/p\Z$ 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/p\Z$.

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.

(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.)

%notest
\beginexample
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" );
\endexample

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

%notest
\beginexample
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 );
\endexample

%notest
\beginexample
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 );
\endexample

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.

%notest
\beginexample
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 );
\endexample

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.

%notest
\beginexample
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 );
\endexample

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~"ref: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.

%notest
\beginexample
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 );
\endexample

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.

%notest
\beginexample
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 );
\endexample

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.

%notest
\beginexample
gap> InstallMethod( DegreeFFE,
>    "for element in Z/pZ",
>    [ IsMyZmodpZObj ],
>    z -> 1 );
\endexample

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.

%notest
\beginexample
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 );
\endexample


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Section{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.

\begintt
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", ... );
\endtt

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.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%E