An operation is defined for elements rather than for objects in the sense
that if the arguments are replaced by objects that are equal to the old
arguments w.r.t. the equivalence relation '=' then the result must be
equal to the old result w.r.t. '='.
But the implementation of many methods is representation dependent in the sense that certain representation dependent subobjects are accessed.
For example, a method that implements the addition of univariate polynomials may access coefficients lists of its arguments only if they are really stored, while in the case of sparsely represented polynomials a different approach is needed.
In spite of this, for many operations one does not want to write an own method for each possible representations of each argument, for example because none of the methods could in fact take advantage of the actually given representations of the objects. Another reason could be that one wants to install first a representation independent method, and then add specific methods as they are needed to gain more efficiency, by really exploiting the fact that the arguments have certain representations.
For the purpose of admitting representation independent code, one can define an external representation of objects in a given family, install methods to compute this external representation for each representation of the objects, and then use this external representation of the objects whenever they occur.
We cannot provide conversion functions that allow us to first convert any object in question to one particular ``standard representation'', and then access the data in the way defined for this representation, simply because it may be impossible to choose such a ``standard representation'' uniformly for all objects in the given family.
So the aim of an external representation of an object obj is a
different one, namely to describe the data from which obj is composed.
In particular, the external representation of obj is not one possible
(``standard'') representation of obj,
in fact the external representation of obj is in general different
from obj w.r.t. '=',
first of all because the external representation of obj does in general
not lie in the same family as obj.
For example the external representation of a rational function is a list of length two or three, the first entry being the zero coefficient, the second being a list describing the coefficients and monomials of the numerator, and the third, if bound, being a list describing the coefficients and monomials of the denominator. In particular, the external representation of a polynomial is a list and not a polynomial.
The other way round, the external representation of obj encodes obj in such a way that from this data and the family of obj, one can create an object that is equal to obj. Usually the external representation of an object is a list or a record.
Although the external representation of obj is by definition independent of the actually available representations for obj, it is usual that a representation of obj exists for which the computation of the external representation is obtained by just ``unpacking'' obj, in the sense that the desired data is stored in a component or a position of obj, if obj is a component object (see Component Objects) or a positional object (see Positional Objects).
To implement an external representation means to install methods for the following two operations.
ExtRepOfObj( obj )
ObjByExtRep( fam, data )
ExtRepOfObj returns the external representation of its argument,
and ObjByExtRep returns an object in the family fam that has
external representation data.
Of course, ObjByExtRep( FamilyObj( obj ), ExtRepOfObj( obj ) )
must be equal to obj.
But it is not required that equal objects have equal external
representations.
Note that if one defines a new representation of objects for which an external representation does already exist then one must install a method to compute this external representation for the objects in the new representation.
[Top] [Previous] [Up] [Next] [Index]
GAP 4 manual