Handling of Bad Coordinate Values

During the process of transforming coordinate data, numerical errors (such as division by zero or overflow) will inevitably occur from time to time. There is no need to include specific protection against this when a transformation is formulated, however, because such errors will automatically be trapped and converted into one of the standard Starlink bad values.⁴

This form of error trapping is performed by all the routines which apply compiled mappings to coordinate data. The resulting ``bad coordinates'' will, where necessary, be propagated through each stage in the evaluation of a compiled mapping, so that all the results which have been affected by numerical errors can later be identified. No error report is currently made (or STATUS value set) if a numerical error of this nature occurs.

All the routines which apply compiled mappings to coordinate data can also recognise bad coordinate values supplied as input, and will propagate these if required. Frequently, however, there will not be any bad coordinates in the input data stream and it may be possible to save appreciable amounts of processing time by disabling recognition of these values (thereby eliminating unnecessary checking), especially when large arrays are being processed. Each relevant routine therefore carries a logical argument called BAD, which specifies whether recognition of bad input data is required (execution will generally be faster if BAD is .FALSE.). Note that this argument only affects recognition of bad data in the input stream, while numerical errors which occur during the computation are always converted into bad values and correctly propagated to the output.