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

In this chapter, we give a –hopefully typical– example of extending **GAP** by new objects with prescribed arithmetic operations (for a simple approach that may be useful to get started though does not permit to exploit all potential features, see also `ArithmeticElementCreator`

(80.9-1)).

A usual procedure in mathematics is the definition of new operations for given objects; here are a few typical examples. The Lie bracket defines an interesting new multiplicative structure on a given (associative) algebra. Forming a group ring can be viewed as defining a new addition for the elements of the given group, and extending the multiplication to sums of group elements in a natural way. Forming the exterior algebra of a given vector space can be viewed as defining a new multiplication for the vectors in a natural way.

**GAP** does *not* support such a procedure. The main reason for this is that in **GAP**, the multiplication in a group, a ring etc. is always written as `*`

, and the addition in a vector space, a ring etc. is always written as `+`

. Therefore it is not possible to define the Lie bracket as a "second multiplication" for the elements of a given algebra; in fact, the multiplication in Lie algebras in **GAP** is denoted by `*`

. Analogously, constructing the group ring as sketched above is impossible if an addition is already defined for the elements; note the difference between the usual addition of matrices and the addition in the group ring of a matrix group! (See Chapter 65 for an example.) Similarly, there is already a multiplication defined for row vectors (yielding the standard scalar product), hence these vectors cannot be regarded as elements of the exterior algebra of the space.

In situations such as the ones mentioned above, **GAP**'s way to deal with the structures in question is the following. Instead of defining *new* operations for the *given* objects, *new* objects are created to which the *given* arithmetic operations `*`

and `+`

are then made applicable.

With this construction, matrix Lie algebras consist of matrices that are different from the matrices with associative multiplication; technically, the type of a matrix determines how it is multiplied with other matrices (see `IsMatrix`

(24.2-1)). A matrix with the Lie bracket as its multiplication can be created with the function `LieObject`

(64.1-1) from a matrix with the usual associative multiplication.

Group rings (more general: magma rings, see Chapter 65) can be constructed with `FreeMagmaRing`

(65.1-1) from a coefficient ring and a group. The elements of the group are not contained in such a group ring, one has to use an embedding map for creating a group ring element that corresponds to a given group element.

It should be noted that the **GAP** approach to the construction of Lie algebras from associative algebras is generic in the sense that all objects in the filter `IsLieObject`

(64.1-2) use the same methods for their addition, multiplication etc., by delegating to the "underlying" objects of the associative algebra, no matter what these objects actually are. Analogously, also the construction of group rings is generic.

The goal of this section is to implement objects with a prescribed multiplication. Let us assume that we are given a field F, and that we want to define a new multiplication * on F that is given by a * b = a b - a - b + 2; here a b denotes the ordinary product in F.

By the discussion in Section 82.1, we know that we cannot define a new multiplication on F itself but have to create new objects.

We want to distinguish these new objects from all other **GAP** objects, in order to describe for example the situation that two of our objects shall be multiplied. This distinction is made via the *type* of the objects. More precisely, we declare a new *filter*, a function that will return `true`

for our new objects, and `false`

for all other **GAP** objects. This can be done by calling `DeclareFilter`

(13.8-2), but since our objects will know about the value already when they are constructed, the filter can be created with `DeclareCategory`

(13.3-5) or `NewCategory`

(13.3-4).

DeclareCategory( "IsMyObject", IsObject );

The idea is that the new multiplication will be installed only for objects that "lie in the category `IsMyObject`

".

The next question is what internal data our new objects store, and how they are accessed. The easiest solution is to store the "underlying" object from the field F. **GAP** provides two general possibilities how to store this, namely record-like and list-like structures (for examples, see 79.2 and 79.3). We decide to store the data in a list-like structure, at position 1. This *representation* is declared as follows.

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

Of course we can argue that this declaration is superfluous because *all* objects in the category `IsMyObject`

will be represented this way; it is possible to proceed like that, but often (in more complicated situations) it turns out to be useful that several representations are available for "the same element".

For creating the type of our objects, we need to specify to which *family* (see 13.1) the objects shall belong. For the moment, we need not say anything about relations to other **GAP** objects, thus the only requirement is that all new objects lie in the *same* family; therefore we create a *new* family. Also we are not interested in properties that some of our objects have and others do not have, thus we need only one type, and store it in a global variable.

MyType:= NewType( NewFamily( "MyFamily" ), IsMyObject and IsMyObjectListRep );

The next step is to write a function that creates a new object. It may look as follows.

MyObject:= val -> Objectify( MyType, [ Immutable( val ) ] );

Note that we store an *immutable copy* of the argument in the returned object; without doing so, for example if the argument would be a mutable matrix then the corresponding new object would be changed whenever the matrix is changed (see 12.6 for more details about mutability).

Having entered the above **GAP** code, we can create some of our objects.

gap> a:= MyObject( 3 ); b:= MyObject( 5 ); <object> <object> gap> a![1]; b![1]; 3 5

But clearly a lot is missing. Besides the fact that the desired multiplication is not yet installed, we see that also the way how the objects are printed is not satisfactory.

Let us improve the latter first. There are two **GAP** functions `View`

(6.3-3) and `Print`

(6.3-4) for showing objects on the screen. `View`

(6.3-3) is thought to show a short and human readable form of the object, and `Print`

(6.3-4) is thought to show a not necessarily short form that is **GAP** readable whenever this makes sense. We decide to show `a`

as

by `3``View`

(6.3-3), and to show the construction `MyObject( 3 )`

by `Print`

(6.3-4); the methods are installed for the underlying operations `ViewObj`

(6.3-5) and `PrintObj`

(6.3-5).

InstallMethod( ViewObj, "for object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], function( obj ) Print( "<", obj![1], ">" ); end ); InstallMethod( PrintObj, "for object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], function( obj ) Print( "MyObject( ", obj![1], " )" ); end );

This is the result of the above installations.

gap> a; Print( a, "\n" ); <3> MyObject( 3 )

And now we try to install the multiplication.

InstallMethod( \*, "for two objects in `IsMyObject'", [ IsMyObject and IsMyObjectListRep, IsMyObject and IsMyObjectListRep ], function( a, b ) return MyObject( a![1] * b![1] - a![1] - b![1] + 2 ); end );

When we enter the above code, **GAP** runs into an error. This is due to the fact that the operation `\*`

(31.12-1) is declared for two arguments that lie in the category `IsMultiplicativeElement`

(31.14-10). One could circumvent the check whether the method matches the declaration of the operation, by calling `InstallOtherMethod`

(78.3-2) instead of `InstallMethod`

(78.3-1). But it would make sense if our objects would lie in `IsMultiplicativeElement`

(31.14-10), for example because some generic methods for objects with multiplication would be available then, such as powering by positive integers via repeated squaring. So we want that `IsMyObject`

implies `IsMultiplicativeElement`

(31.14-10). The easiest way to achieve such implications is to use the implied filter as second argument of the `DeclareCategory`

(13.3-5) call; but since we do not want to start anew, we can also install the implication afterwards.

InstallTrueMethod( IsMultiplicativeElement, IsMyObject );

Afterwards, installing the multiplication works without problems. Note that `MyType`

and therefore also `a`

and `b`

are *not* affected by this implication, so we construct them anew.

gap> MyType:= NewType( NewFamily( "MyFamily" ), > IsMyObject and IsMyObjectListRep );; gap> a:= MyObject( 3 );; b:= MyObject( 5 );; gap> a*b; a^27; <9> <134217729>

Powering the new objects by negative integers is not possible yet, because **GAP** does not know how to compute the inverse of an element a, say, which is defined as the unique element a' such that both a a' and a' a are "the unique multiplicative neutral element that belongs to a".

And also this neutral element, if it exists, cannot be computed by **GAP** in our current situation. It does, however, make sense to ask for the multiplicative neutral element of a given magma, and for inverses of elements in the magma.

But before we can form domains of our objects, we must define when two objects are regarded as equal; note that this is necessary in order to decide about the uniqueness of neutral and inverse elements. In our situation, equality is defined in the obvious way. For being able to form sets of our objects, also an ordering via `\<`

(31.11-1) is defined for them.

InstallMethod( \=, "for two objects in `IsMyObject'", [ IsMyObject and IsMyObjectListRep, IsMyObject and IsMyObjectListRep ], function( a, b ) return a![1] = b![1]; end ); InstallMethod( \<, "for two objects in `IsMyObject'", [ IsMyObject and IsMyObjectListRep, IsMyObject and IsMyObjectListRep ], function( a, b ) return a![1] < b![1]; end );

Let us look at an example. We start with finite field elements because then the domains are finite, hence the generic methods for such domains will have a chance to succeed.

gap> a:= MyObject( Z(7) ); <Z(7)> gap> m:= Magma( a ); <magma with 1 generator> gap> e:= MultiplicativeNeutralElement( m ); <Z(7)^2> gap> elms:= AsList( m ); [ <Z(7)>, <Z(7)^2>, <Z(7)^5> ] gap> ForAll( elms, x -> ForAny( elms, y -> x*y = e and y*x = e ) ); true gap> List( elms, x -> First( elms, y -> x*y = e and y*x = e ) ); [ <Z(7)^5>, <Z(7)^2>, <Z(7)> ]

So a multiplicative neutral element exists, in fact all elements in the magma `m`

are invertible. But what about the following.

gap> b:= MyObject( Z(7)^0 ); m:= Magma( a, b ); <Z(7)^0> <magma with 2 generators> gap> elms:= AsList( m ); [ <Z(7)^0>, <Z(7)>, <Z(7)^2>, <Z(7)^5> ] gap> e:= MultiplicativeNeutralElement( m ); <Z(7)^2> gap> ForAll( elms, x -> ForAny( elms, y -> x*y = e and y*x = e ) ); false gap> List( elms, x -> b * x ); [ <Z(7)^0>, <Z(7)^0>, <Z(7)^0>, <Z(7)^0> ]

Here we found a multiplicative neutral element, but the element `b`

does not have an inverse. If an addition would be defined for our elements then we would say that `b`

behaves like a zero element.

When we started to implement the new objects, we said that we wanted to define the new multiplication for elements of a given field F. In principle, the current implementation would admit also something like `MyObject( 2 ) * MyObject( Z(7) )`

. But if we decide that our initial assumption holds, we may define the identity and the inverse of the object `<a>`

as `<2*e>`

and `<a/(a-e)>`

, respectively, where `e`

is the identity element in F and `/`

denotes the division in F; note that the element `<e>`

is not invertible, and that the above definitions are determined by the multiplication defined for our objects. Further note that after the installations shown below, also `One( MyObject( 1 ) )`

is defined.

(For technical reasons, we do not install the intended methods for the attributes `One`

(31.10-2) and `Inverse`

(31.10-8) but for the operations `OneOp`

(31.10-2) and `InverseOp`

(31.10-8). This is because for certain kinds of objects –mainly matrices– one wants to support a method to compute a *mutable* identity or inverse, and the attribute needs only a method that takes this object, makes it immutable, and then returns this object. As stated above, we only want to deal with immutable objects, so this distinction is not really interesting for us.)

A more interesting point to note is that we should mark our objects as likely to be invertible, since we add the possibility to invert them. Again, this could have been part of the declaration of `IsMyObject`

, but we may also formulate an implication for the existing category.

InstallTrueMethod( IsMultiplicativeElementWithInverse, IsMyObject ); InstallMethod( OneOp, "for an object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], a -> MyObject( 2 * One( a![1] ) ) ); InstallMethod( InverseOp, "for an object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], a -> MyObject( a![1] / ( a![1] - One( a![1] ) ) ) );

Now we can form groups of our (nonzero) elements.

gap> MyType:= NewType( NewFamily( "MyFamily" ), > IsMyObject and IsMyObjectListRep );; gap> gap> a:= MyObject( Z(7) ); <Z(7)> gap> b:= MyObject( 0*Z(7) ); g:= Group( a, b ); <0*Z(7)> <group with 2 generators> gap> Size( g ); 6

We are completely free to define an *addition* for our elements, a natural one is given by `<a> + <b> = <a+b-1>`

. As we did for the multiplication, we first change `IsMyObject`

such that the additive structure is also known.

InstallTrueMethod( IsAdditiveElementWithInverse, IsMyObject );

Next we install the methods for the addition, and those to compute the additive neutral element and the additive inverse.

InstallMethod( \+, "for two objects in `IsMyObject'", [ IsMyObject and IsMyObjectListRep, IsMyObject and IsMyObjectListRep ], function( a, b ) return MyObject( a![1] + b![1] - 1 ); end ); InstallMethod( ZeroOp, "for an object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], a -> MyObject( One( a![1] ) ) ); InstallMethod( AdditiveInverseOp, "for an object in `IsMyObject'", [ IsMyObject and IsMyObjectListRep ], a -> MyObject( a![1] / ( a![1] - One( a![1] ) ) ) );

Let us try whether the addition works.

gap> MyType:= NewType( NewFamily( "MyFamily" ), > IsMyObject and IsMyObjectListRep );; gap> a:= MyObject( Z(7) );; b:= MyObject( 0*Z(7) );; gap> m:= AdditiveMagma( a, b ); <additive magma with 2 generators> gap> Size( m ); 7

Similar as installing a multiplication automatically makes powering by integers available, multiplication with integers becomes available with the addition.

gap> 2 * a; <Z(7)^5> gap> a+a; <Z(7)^5> gap> MyObject( 2*Z(7)^0 ) * a; <Z(7)>

In particular we see that this multiplication does *not* coincide with the multiplication of two of our objects, that is, an integer *cannot* be used as a shorthand for one of the new objects in a multiplication.

(It should be possible to create a *field* with the new multiplication and addition. Currently this fails, due to missing methods for computing several kinds of generators from field generators, for computing the characteristic in the case that the family does not know this in advance, for checking with `AsField`

(58.1-9) whether a domain is in fact a field, for computing the closure as a field.)

It should be emphasized that the mechanism described above may be not suitable for the situation that one wants to consider many different multiplications "on the same set of objects", since the installation of a new multiplication requires the declaration of at least one new filter and the installation of several methods. But the design of **GAP** is not suitable for such dynamic method installations.

Turning this argument the other way round, the implementation of the new arithmetics defined by the above multiplication and addition is available for any field F, one need not repeat it for each field one is interested in.

Similar to the above situation, the construction of a magma ring RM from a coefficient ring R and a magma M is implemented only once, since the definition of the arithmetic operations depends only on the given multiplication of M and not on M itself. So the addition is not implemented for the elements in M or –more precisely– for an isomorphic copy. In some sense, the addition is installed "for the multiplication", and as mentioned in Section 82.1, there is only one multiplication `\*`

(31.12-1) in **GAP**.

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

generated by GAPDoc2HTML