MaxTranSimplifying IntraMaps

A notable disadvantage of IntraMaps is that they are “black boxes” as far as AST is concerned. This means that they have limited ability to participate in the simplification of compound Mappings performed, e.g., by astSimplifyastSimplify (§6.7), because AST cannot know how they interact with other Mappings. In reality, of course, they will often implement such specialised coordinate transformations that the simplification possibilities will be rather limited anyway.

One important simplification, however, is the ability of a MappingMapping to cancel with its own inverse to yield a unit Mapping (a UnitMapUnitMap). This is important because Mappings are frequently used to relate a dataset to some external standard (a celestial coordinate system, for example). When inter-relating two similar datasets calibrated using the same standard, part of the Mapping often cancels, because it is applied first in one direction and then the other, effectively eliminating the reference to the standard. This is often a useful simplification and can lead to greater efficiency.

Many transformations have this property of cancelling with their own inverse, but not necessarily all. Consider the following transformation function, for example:


\begin{terminalv}
void MaxTran( AstMapping *this, int npoint, int ncoord_in,
co...
... {
ptr_out[ coord ][ point ] = ptr_in[ 0 ][ point ];
}
}
}
}
\end{terminalv}

This function takes any number of input coordinates and returns a single output coordinate which is the maximum value of the input coordinates. Its inverse (actually a “pseudo-inverse”) sets all the input coordinates to the value of the output coordinate.[*]

If this function is applied in the forward direction and then in the inverse direction, it does not in general restore the original coordinate values. However, if applied in the inverse direction and then the forward direction, it does. Hence, replacing the sequence of operations with an equivalent UnitMap is possible in the latter case, but not in the former.

To distinguish these possibilities, two flag values are provided for use with astIntraRegastIntraReg to indicate what simplification (if any) is possible. For example, to register the above transformation function, we might use:


\begin{terminalv}
void MaxTran( AstMapping *, int, int, const double *[], int, i...
... AST__ANY, 1, MaxTran, AST__SIMPIF,
purpose, author, contact );
\end{terminalv}

Here, the flag value AST__SIMPIF supplied for the fifth argument indicates that simplification is possible if the transformation is applied in the inverse direction followed by the forward direction. To indicate the complementary case, the flag AST__SIMPFI would be used instead. If both simplifications are possible (as with the SqrTran function in §20.4), then we would use the bitwise OR of both values.

In practice, some judgement is usually necessary when deciding whether to allow simplification. For example, seen in one light our SqrTran function (§20.4) does not cancel with its own inverse, because squaring a coordinate value and then taking its square root can change the original value, if this was negative. Therefore, replacing this combination with a UnitMap will change the behaviour of a compound Mapping and should not be allowed. Seen in another light, however, where the coordinates being processed are intrinsically all positive, it is a permissible and probably useful simplification.

If such distinctions are ever important in practice, it is simple to register the same transformation function twice with different flag values (use a separate name for each) and then use whichever is appropriate when creating an IntraMapIntraMap.