Applicability & Efficiency

The NUM_ functions are the most flexible routines in this package. Being implemented as statement functions, they will normally be expanded ``in-line'' by the VAX Fortran compiler and may therefore be used in any situation without incurring the overhead of an external function call. The expanded function definition can subsequently take part in the compiler's optimisation process and will therefore result in code which executes very efficiently (although some of the machine-specific features used by VEC_ routines cannot be accessed in this way).

However, the NUM_ functions are also the least robust routines in this package. This is because they incorporate no protection against numerical errors (such as division by zero or overflow), neither do they generate or recognise bad data -- which they will always treat as valid. If a numerical error occurs when a NUM_ function is invoked, the application will immediately terminate (i.e. crash).

The robustness of NUM_ functions may be improved by incorporating explicit checks on the numbers being processed and by ensuring that the functions are not invoked if their arguments may be undefined (under error conditions, for instance). Such checks will always degrade the execution efficiency, however, and the equivalent VEC_ routine (section ) is then likely to be at least as efficient. Consequently, use of the NUM_ functions is generally appropriate only when:

• It is known (from the nature of the data) that numerical errors cannot occur; or

• Efficiency considerations completely outweigh the need for robustness; or

• The problem is such that no alternative routine from this package is applicable.

For applications where VAX-specific code is acceptable, the NUM facility also includes a simple VAX condition handler which can be used to recover from numerical errors (section ). This may be used with the NUM_ functions (and Fortran arithmetic expressions) to combine robustness with efficiency and flexibility in cases where other routines from this package are not suitable. However, the programming effort required is relatively high and the resulting applications will not be portable.