# 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).

##