Arithmetic overflow/underflow

Overflow
On a Win32 platform, FTN95 always tests for floating point overflow. Integer overflow is tested in CHECKMATE mode only. Floating point underflow, which (depending on the algorithm) may or may not represent a true error, can optionally be trapped. This strategy reflects the fact that, for INTEL architectures, integer overflow detection is more expensive than floating point overflow detection.

When integers overflow (in Win32 or .NET code) the result is essentially meaningless and can be of either sign. On a .NET platform, the result of a floating point overflow is stored as one of two pseudo-numbers representling 'plus infinity' and 'minus infinity'.

The .NET framework caters for a range of platforms with differing CPUs. Because of this, automatic overflow checking for both integer and floating point quantities is only provided in CHECKMATE mode. When CHECKMATE is used, an exception is raised when overflow occurs. When CHECKMATE is not used, by default overflow is not detected and a calculation will continue using values that are meaningless.

FTN95 provides an intrinsic subroutine called CHECK_FINITE@. This routine takes a single REAL or COMPLEX scalar variable as an argument and raises an exception if the argument is not finite (a COMPLEX variable is deemed to be infinite if either the real or imaginary part is infinite). The exception can be handled by using a TRY block. Because of a potentially high overhead, CHECK_FINITE@ should only be called at selected points in the code and after calculations that are considered to be sensitive and liable to floating-point overflow.

In CHECKMATE mode, FTN95 automatically calls CHECK_FINITE@ after each floating-point calculation. For release mode your program can make calls to CHECK_FINITE@ at selected points in order to raise an exception if floating-point overflow occurs. Alternatively, for release mode the FTN95 command line option /OVERFLOW can be used to automatically call CHECK_FINITE@ after each floating point calculation.

 

Underflow
On a Win32 platform, FTN95 allows you to detect floating point underflow by either a) calling PERMIT_UNDERFLOW@(.FALSE.) or b) using /UNDERFLOW on the command line (in which case the call to PERMIT_UNDERFLOW@ is planted for you. If you do not permit underflow, an exception is raised at runtime when an underflow occurs.

Currently there is no mechanism available that allows FTN95 to implement PERMIT_UNDERFLOW@ for .NET. The only way to check for underflow is to test your program in Win32 mode.

Floating point numbers are represented using a significand and an exponent. Maximum precision is obtained by adjusting the exponent so that the leading binary digit of the significand is a one rather than a zero. A non-zero significand that has a leading zero is called a denormal. When the minimum exponent (typically 1E-38 for single precision) is reached, smaller numbers are accommodated by using denormals with decreasing precision until (typically at 1E-46 for single precision) all significant figures are lost and the value is truncated to zero.

Although for many purposes the effects of underflow can be ignored, it is important to note two factors:

a) As values become very small they will have fewer significant figures and (in particular) the different of two small values could easily become meaningless.

b) Calculations involving denormals will be significantly slower (particularly on a Pentium 4).