Exceptions in IEEE 754 Arithmetic

[David Hough]

The silliness factor in comp.std.c got too high, so I posted the
following.  Sorry if you have to delete it twice:

 From postnews Tue Jun  5 20:08:04 1990
Followup-To: poster
Subject: Exceptions in IEEE 754 Arithmetic
Newsgroups: comp.std.c,comp.arch,comp.lang.fortran

There have been some unusual views about IEEE 754 floating-point
exception handling expressed in comp.std.c recently.  The following
reviews the intentions and requirements of the standard.

The standard requires that the default mode of execution be nonstop
with respect to exceptions.  Here are some reasons why:

1) It would be very annoying to stop and terminate for every rounding
error.

2) All exceptions should be treated uniformly.

3) There is no uniformity of trap handling among hardware, operating
systems, and languages.  There is no portable way to build IEEE 754
behavior on top of ANSI C signal handlers, for instance.

4) If any exceptions were trapped by default, then trap handling would
be required in all implementations of IEEE 754.

5) Many real-time systems have no unexpected exceptions and thus no use
for mandatory traps on them.


There are two classes of exceptions; these could be called "expected"
and "unexpected".  Most applications expect normal rounding errors
(inexact exceptions).  Some applications expect underflow; fewer expect
overflow or division by zero.  (This is primarily because most existing
applications were written to be portable across systems which
collectively provide no reliable behavior in the face of all these
exceptions.)   But an algorithm to evaluate continued fractions is
immune to underflow, overflow, and division by zero, provided only that
the default is to continue with sensible defaults as IEEE 754
provides.  APL applications fairly routinely operate on vectors
containing some undefined data; exceptions in that part of the vectors
shouldn't impede normal progress.  But in more conventional languages
most exceptions are unexpected
during initial program debugging; so complete IEEE environments should
provide the optional trapping capability.

So what is expected and what is unexpected is a function of the
application, the language, and the skill of the programmer, 
and exceptions can't be
standardized a-priori one way or the other.  Since the most refractory
errors in floating-point programs have to do with roundoff
rather than other rarer exceptions, the only completely safe
operational mode is to dump core at the first rounding error.  If you
think this is ridiculous you should think of all the realistic
applications you know of that have been PROVEN to be correct despite
roundoff.

But IEEE 754 is primarily intended to make it easier to write efficient
new applications, without making old portable applications run worse
(old non-portable applications aren't expected to run on IEEE 754
systems.)  Old applications that are portable can't rely on any
particular sort of exception handling except that rounding errors will
be ignored.  (That of course means that detecting whether rounding
errors have occurred is very difficult when you need to do so.)

Since it would be a bad idea to abort on all dangerous errors, and
impossible to recover from a gratuitous trap in a portable way, the
uniform IEEE 754 default is to continue with a default result and an
exception flag.  The intent is that questionable default results will
propagate NaNs that affect the final output if they matter, and that
the exception flags will be reported in some way unless they are
explicitly cleared by the program or user.  The IEEE 754 committee
couldn't think of a way to specify such a capability that made sense in
all the anticipated environments.  But in Sun Fortran 1.3, for
instance, the ieee_retrospective function places retrospective
diagnostic messages in standard error, including whether any exception
flags are still standing and whether any non-standard execution modes
are still enabled.

(Fortran 1.3 (and C 1.0) also provide a compilation option "-fast" for
users of programs portable among pre-IEEE arithmetic systems, who would
like to run those programs on IEEE 754 systems in much the same way and
who refuse to read more than one page of documentation.   People who
are willing to read more can find it in a new manual called the
Numerical Computation Guide which updates and extends the previous
Floating-Point Programmer's Guide.  Numerical Computation Guide readers
are invited to send comments for future editions to dghasun.com .)

The discussion in comp.std.c has mostly missed the main shortcoming of
IEEE 754, that it did not include language bindings to C and Fortran
for all its features.  Consequently many implementers have found it
convenient to claim to provide an IEEE 754-conforming programming
environment without bothering to include the most important aspects of
such an environment.

Copies of ANSI/IEEE Std 754-1985 are available from ANSI and from IEEE,
surprisingly enough.

The Numerical C Extensions Group is preparing a report of
recommendations on a number of issues, including IEEE language bindings
for ANSI C.  Besides the latter, which affect only implementations of
both IEEE 754 and ANSI C, I expect that an implementation that accepts
all NCEG recommendations will remove all further excuses for continuing
to develop new applications in Fortran.  For more information on NCEG,
contact the convener, Rex Jaeschke, 
	uunet!aussie!rex

In addition I maintain an occasionally-lively numeric-interest mailing
list for discussions of IEEE floating point and elementary
transcendental functions and related issues.   Persons interested in
getting on that list should send a message to
	{sun,uunet}!validgh!numeric-interest-request