An application seeking access to an NDF array component will not usually be concerned with the actual numeric type used to store the values and will request a type which suits whatever processing is to be performed. Single-precision (i.e. `_REAL') values are normally most appropriate and have been specified in previous examples.
Nevertheless the third (TYPE) argument to NDF_MAP may be used to specify any of the seven numeric types supported by the NDF_ system (see §) and a mapped array of values having the requested type will be made available. For instance:
CALL NDF_MAP( INDF, 'Data', '_WORD', 'READ', PNTR, EL, STATUS )
will map an array of `_WORD' (i.e. Fortran INTEGER2) values, performing type conversion automatically if required. If the component's values are being written or modified, then type conversion will also be performed, in reverse, when it is unmapped. The resulting ``back-converted'' values are used to update the NDF.
Unfortunately, type conversion takes time, so it may sometimes be worth avoiding if possible. This can be done, although only at the expense of some additional programming effort, by calling NDF_TYPE to determine the numeric type of a component which is to be mapped and using the same type for access, so that type conversion becomes unnecessary, for instance:
INCLUDE 'NDF_PAR' CHARACTER * ( NDF__SZTYP ) TYPE ... CALL NDF_TYPE( INDF, TYPE, STATUS ) CALL NDF_MAP( INDF, 'Variance', TYPE, 'READ', PNTR, EL, STATUS )
The application must then be prepared to explicitly process whatever numeric
type is supplied, which will normally mean duplicating the main processing
algorithm for each possible type.
Such steps are not justified for normal use, but may sometimes be adopted
for general-purpose software which will be heavily used.
The GENERIC compiler (see SUN/7) can be useful for
generating the necessary multiple copies of suitably-written
algorithms if this approach is to be used.