5 More Advanced Topics

5.1 Classifying Transformations

As well as holding mapping information describing how to convert from one coordinate system to another, a transformation may also carry information about the character of its mappings. When plotting a graph, for instance, it may be important to know whether the mapping being used is linear, because a more complex (and costly) algorithm may be required if it is not. Indeed, in many circumstances, the absence of a vital property such as linearity could actually make it impossible for an application to proceed, in which case it must issue an appropriate error message and abort.

There are a number of mapping characteristics, in addition to linearity, which can influence or simplify the coding of applications in this way. However, it is often difficult to determine by indirect means (such as transforming test points) whether the necessary special properties are present. Provision has therefore been made for handling this type of information explicitly. Classification properties.  Usually, information about any special characteristics which are present is directly available only to the application which creates a transformation. Consequently, this application should be responsible for declaring that such properties are present, so that other applications may subsequently enquire about them. This process is termed classification and the basic classification properties which may be declared are indicated in Table 1, where each is briefly described. These properties are defined more precisely (and mathematically) in Appendix B.

would indicate that a mapping represents a rigid rotation about an axis (or a point in two dimensions). Facts such as this may not be obvious without some thought, however, so those classifications which apply to a number of the most common types of mapping are set out in Table 4 in Appendix B.

Classification information is conveniently processed in the form of a 1-dimensional logical classification array, each of whose elements indicates the presence or absence of one particular property. Each basic property therefore has an integer symbolic constant associated with it (see Table 1) which identifies the array element to be used (the precise mechanism is illustrated below). Not all possible combinations of the basic properties are permitted (see Appendix B) but the number of different classifications possible is nevertheless still quite large. Inserting classification information.  It is important to appreciate that classifying a transformation is not mandatory, but merely assists other applications in making effective use of it. The desirability of classification therefore depends largely on the type of applications which are likely to process the transformation. For instance, a comprehensive general-purpose application, which might be used in conjunction with a wide range of other software, would probably take care to classify a transformation fully, whereas a simpler application, perhaps designed for personal use, might not. However, a declaration of linearity, if it applies, is generally recommended. When a transformation is first created using TRN_NEW it has no classification information associated with it, so this information has to be inserted explicitly. This is done by calling TRN_PTCL (put classification), as follows:

Example 11. Inserting classification information.

Programming notes:

(1)

A 1-dimensional logical array CLASS is declared with TRN__MXCLS elements (this symbolic constant specifies the number of basic classification properties currently recognised and is defined in the include file TRN_PAR).

(2)

A transformation is created. At this point it does not contain any classification information.

(3)

All elements of the CLASS array are explicitly initialised to .FALSE. – this precaution is recommended so that the number of basic classification properties may be increased in future without adversely affecting existing software.

(4)

The required array elements are set to .TRUE. – in this example the classification describes a simple linear magnification about a point with a positive magnification factor (see Table 4 in Appendix B). Symbolic constants (also defined in the include file TRN_PAR) are used to identify the array elements concerned.

(5)

The classification information is entered into the transformation by calling TRN_PTCL.

Example 12. Retrieving classification information.

Programming notes:

(1)

A logical array CLASS is declared with TRN__MXCLS elements.

(2)

TRN_GTCL is called to retrieve classification information from a transformation, returning it in the CLASS array. The second (logical) argument to TRN_GTCL is set .TRUE. in this example, which indicates that information is required about the forward mapping (as opposed to the inverse mapping). An error would result if this mapping were not defined.

(3)

The appropriate elements of the CLASS array are tested to determine whether the mapping has the required property. In this case, OK is set .TRUE. if the forward mapping is LINEAR and ISOTROPIC. In two dimensions this would ensure that it preserves straight lines, angles and shapes (e.g. circles).

The routine TRN_GTCLC (get compiled classification) is also provided to retrieve classification information from compiled mappings (Appendix D). Automatic classification processing.  The TRANSFORM software provides for a certain amount of automatic processing to take place whenever an exchange of classification information occurs. The simplest form which this takes is validation, which will detect errors such as an attempt to declare an inconsistent set of classification properties. In addition, the software is capable of “filling in” any properties which are missing but which can be deduced from the others supplied. Some instances where properties can be deduced in this way are indicated by the open circles in Table 4 – it would not be necessary to specify these items explicitly, as TRANSFORM routines would supply them automatically. Automatic processing also takes place whenever transformations are concatenated, prefixed or appended (Sections 4.3 & 4.4). In this case, the classification information available from each of the contributing transformations is combined to deduce the set of properties which apply to the result. Note, however, that only those properties which necessarily follow can be deduced in this way. For instance, it would be possible for the non-linearities in two mappings to cancel when their transformations are concatenated, giving an overall linear result. However, since this is not the case in general, it could not be deduced automatically. If the automatic classification processing provided should prove inadequate (for instance, the application may have some additional information available to it), then a new classification may be derived explicitly and “re-declared” by calling TRN_PTCL, which will replace any pre-existing classification information.

5.2 Arithmetic Precision

When a transformation is created, a precision specification is associated with it (i.e. via the PREC argument to TRN_NEW – Section 3.2) and this subsequently determines the type of arithmetic (integer, real or double precision) which will be used to evaluate the transformation functions. The correct choice of this specification is important if the desired behaviour is to be achieved. Two considerations normally apply:

(1)

The type of calculation being performed. For instance, integer arithmetic might be required if effects due to rounding were being exploited, whereas transformation functions representing a 2-dimensional rotation would probably need to use real arithmetic, even if the coordinate data were to be stored as integers. Some functions may also require double precision arithmetic to reduce internal rounding errors.

(2)

The type of data being transformed. It would clearly be inappropriate to use real arithmetic on double precision data but, conversely, it would be inefficient to use a higher precision than was necessary to preserve the accuracy of real data.

It can be seen that an appropriate arithmetic precision cannot necessarily be selected solely on the basis of the type of calculation to be performed, because the type of coordinate data to be processed may also be relevant. Unfortunately, this latter information may not be available to the application which creates the transformation. Furthermore, whenever transformations are concatenated (Section 4.3), each must be able to accommodate data passed to it by neighbouring transformations although it may not have any advance knowledge of the type of arithmetic its neighbours will be using.

To accommodate these possibilities without unnecessary loss of data precision, transformations are allowed some flexibility in adapting their internal arithmetic to the external data being processed. This is controlled by the precision specification, which is a character string taking one of the following six values:

Fixed precisions specify the type of arithmetic to be used explicitly. In this case, the data used in the calculation (both incoming coordinates and explicit numerical constants in the transformation functions) are first converted to the specified numerical type (integer, real or double precision) and the transformation functions are then evaluated using the appropriate type of arithmetic.

N.B. It is currently assumed that the data types of all the input and output coordinates are the same and all the transformation functions are therefore evaluated using the same type of arithmetic. This may change in future to allow coordinates to have mixed data types. The present arrangement is designed so that changes to existing applications and datasets will not generally be necessary.

Elastic precisions are similar, except that some subsequent adjustment is also allowed. In this case, the precision specification indicates the minimum precision of the arithmetic to be used, but this may be increased if the data type warrants it. Thus, a precision specification of ‘_REAL:’ would request that real arithmetic be used unless double precision data were being processed (in which case double precision arithmetic would be used instead). In general, the type of arithmetic used is related to the precision specification and the type of data being processed as follows:

Once the arithmetic precision has been decided, the transformation functions are evaluated in the same way as for a fixed precision (i.e. by converting all incoming data and constants to the appropriate data type and then performing the arithmetic).

When several transformations have been concatenated, the type of arithmetic to be used is determined individually for each stage in the overall transformation (data type conversion being performed automatically between each stage as necessary). If an elastic precision (which is sensitive to the input data type) has been specified, then the input data type is taken to correspond with the type of arithmetic used in the previous mapping to be evaluated (or the input data type itself if appropriate). This arrangement avoids any unnecessary loss of data precision regardless of the order in which transformations are concatenated.