(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 may check the result of every individual 
 arithmetical operation and take some action.

 IEEE arithmetic requires checking for the following conditions and 
 automatic modifying the result to conform with the extended IEEE 
 arithmetic (see below):

                                                                Default result
  Exception name     Generating conditions                      with no traps 
  -----------------  ----------------------------------------   --------------
  OVERFLOW           Result larger than the maximum possible    +/- infinity,
                                                                or:  +/- Xmax
  UNDERFLOW          Result smaller than the minimum possible   0, +/- Xmin, 
  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:        mod(X,0), mod(infinity,y)     "
                     Square root:     sqrt(X) when X .lt. 0         "

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

          Xmax - maximal representable number
          Xmin - minimal representable number

 Another available option in IEEE arithmetic is to establish a "trap" 
 that will take some specified action when the condition is met.

 IEEE extended non-stop arithmetic
 IEEE arithmetic extends the real number system by the two infinities.
 This procedure is known in mathematics as "Compactification of the
 real line", and serves to ....... 

 To make the new system closed under arithmetic operations, another
 type of symbols has to be added:  the NaNs (Not A Number), which are 
 the results of INVALID OPERAND operations.  Yet other beasts in the 
 IEEE zoo are the signed zeros.

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

 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.

 The first case may be illustrated by computing the relative error
 of two numbers:

      program test1
      real	x, y, ZERO
      parameter	(ZERO = 0.0E0)
      write (*,*) 'Enter two real numbers: '
      read (*,*) x, y
      if (y .ne. ZERO) then
        write (*,*) 'Relative error is: ', x / y
        write (*,*) 'Relative error cannot be computed '

 With IEEE arithmetic we don't have to write the conditional statement,
 if "y" is zero then the result of "x/y" will be an infinity, and the
 "write" statement will take care of it:

      program test2 
      real	x, y, ZERO
      parameter	(ZERO = 0.0E0)
      write (*,*) 'Enter two real numbers: '
      read (*,*) x, y
      write (*,*) 'Relative error is: ', x / y

 Running such a program may give the following:

     Enter two real numbers: 
    1.0 0.0
     Relative error is:  Inf           

 The second case may be illustrated by trying values of some function
 in order to find some special point, e.g. a point where the value of 
 the function is zero.  A possible example may be:

   y  =  ----- - 0.5
         x - 1

 While trying we may stumble upon a point (namely "1") where computing 
 the value leads to division by zero.  In non-stop arithmetic nothing 
 bad happens, we get an extended result that tells us what happeed, 
 and can go on to try another point.  With non-non-stop arithmetic 
 the program is aborted, and we cannot continue the calculation.

 Non-stop arithmetic seems a nice improvement, but 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:

    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)

 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

Return to contents page