4-5  FLOATING-POINT EXCEPTIONS
******************************

(Thanks to Sergio Gelato for the good comments on this chapter)

IEEE exceptions
---------------
While the CPU (or the FPU - Floating Point Unit) crunches your floating
point numbers, the hardware checks the result of every calculation. The
FPU can test the result of every individual addition or multiplication
for the following conditions (depends on the hardware):

Default result
Exception          Generating conditions                      with no traps
-----------------  ----------------------------------------   --------------
OVERFLOW           Result larger than the maximum possible    +/- infinity,
+/- Xmax
UNDERFLOW          Result smaller than the minimum possible   0, +/- Xmin,
Denormalized
DIVIDE BY ZERO     A division by zero was attempted           +/- infinity

INVALID OPERANDS   Addition:        +infinity + (-infinity)      NaN
Multiplication:  0 * infinity                  "
Division:        0/0, infinity/infinity        "
Reminder:        X REM 0, infinity REM y       "
Square root:     X**0.5  when X .LT. 0         "

INEXACT OPERATION  Result was rounded off (quite normal!)    Rounded number

Xmax - maximal representable number
Emin - minimal representable number

The IEEE extended arithmetic
----------------------------
IEEE arithmetic extends the real number system by the two infinities.
To make the new system closed under addition and multiplication it adds
also NaNs (results of INVALID OPERAND operations), and signed zeros.

In the extended arithmetic a result is defined for every arithmetical
operation, there is never an arithmetical need to abort a calculation.
A result - either an ordinary real number, or one of the extended
quantities is produced, and the calculation proceeds.

The philosophy behind IEEE non-stop arithmetic maintains that the
extended real system simplifies programming in some cases, and is
useful when doing calculations that involve singular points.

Many users find the extended arithmetic confusing, and prefer to
have calculations aborted with an appropriate error message when
extended real results are produced.

Exceptions in unextended arithmetic
-----------------------------------
In a "normal" (i.e. done with unextended arithmetic) computation, none of
the exceptions (except INEXACT) may occur, and their occurrence signifies
one (or more) of the following:

1) There is a bug in the program, some intermediary calculation
is done in the wrong way.

2) The input data to the program is bad.

3) A bad algorithm was used, or the problem was improperly
analyzed before the program was written.

4) The problem/algorithm requires larger type of floating-point
numbers with larger range and 'density'

Having the operating system report these conditions is an invaluable
tool for the programmer, helping him to locate problems that are
otherwise hard to trace.

Many users don't know that current IEEE-based workstations often don't
trap *any* FP exceptions by default. It's important that users of these
systems (Sun, IBM RS/6000, HP 9000/700 and HP 9000/800, probably others)
will know how to trap overflows, invalid operands, and divisions by zero,
if they need.

To enable trapping of all exceptions:

FORTRAN/CHECK=(UNDERFLOW,OVERFLOW)              (VMS)
f77 -fnonstd                                    (Sun)
xlf -qflttrap=inv:ov:zero:en:imp                (IBM)
f77 +FPVZOuiD     (at link time)                (HPUX)
(system call or environment variable)         (IRIX)
f77 -check underflow overflow                   (DUNIX)
f77 -check underflow overflow                   (ULTRIX)
(UNICOS)

The default behaviour of the IEEE standard of floating-point arithmetic,
now implemented in most computers is to deliver a 'result' and continue
in the computation.

Underflow exceptions
--------------------
Underflow occurs when the result (in absolute value) is less than
the float type can represent, remember that there are gaps around
zero in the three-segment representation of the number-space.

It is clear that if we got an underflow condition the 'true' result
must be very small - lesser than the smallest float, so it seems
reasonable to handle that condition by assigning the value zero
to the result.

However, 'assign zero' underflow handling can create unexpectedly
large errors (see the section errors of floating points), so a
better possibility may be to abort the program.

In any case the programmer (at least at the program development stage)
must get an error message alerting him to that condition.

Almost all machines let you choose between the two possibilities with
compiler switches, other machines may require system calls

A word would be useful on gradual vs. abrupt underflow. The IEEE default
is gradual underflow (denormalized numbers). Abrupt underflow (set the
result to zero right away on underflow) makes many algorithms converge
faster, and is almost always appropriate.

VS Fortran on IBM S/370 and ES/390 systems ("mainframes") running VM/CMS,
MVS, AIX/370 or AIX/ESA traps underflow by default. Programs often run
twice as fast if this trapping is disabled, which can be done by a
CALL XUFLOW(0) from within Fortran, or at run-time by giving a special
keyword (noxuflow, or -nospie under AIX) on the command line.

Overflow exceptions
-------------------

Invalid operand exceptions
--------------------------

Division by zero exceptions
---------------------------