Language-Compatible Arithmetic

[David Hough]

Donn Terry comments:

> As you may know, I had proposed some tightening up of the math (trig, etc.)
> functions for C so that the error reporting conditions would be consistent
> at least across POSIX implementations.  One of the elements of feedback
> I got was inconsistent information about whether, when an exception occurs,
> it should be signaled immediately or saved in the result value (as an
> INF or NAN).  The C committee clearly decided that the "print a message"
> school of thought was inappropriate by deviating from existing practice
> with matherr.
> 
> In the Paper in SigPlan Notices (V 25 No. 1, January 1990) titled
> "Proposal for a Language Compatible Arithmetic Standard" the authors
> propose that if an exception (in this case, simple arithmetic) should
> occur it must be signalled either with a textual message or with some
> sort of forced change of flow of control (basically, in C terms, a
> signal).  This seems to conflict with much of the input I received that
> neither messages nor flow of control changes were appropriate, particularly
> for highly parallell machines, and that exceptional result values (which
> propigate) were preferred.

Specifying exceptions in high-performance systems is pretty serious business.
You can't count on being able to resume after a signal in any kind of
portable way, relying just on what's in ANSI-C.  
Generally you want to continue past anticipated errors if the default handling
is appropriate, without stopping or printing error messages.

That's why I advocate that language standards, that intend to be useful on
systems that don't implement IEEE arithmetic, should handle exceptions in
a uniform way across the hardware and software-implemented functions, and
whether uni- or multi-processing.  So the libm spec can be simplified to
identify specific exceptions in transcendental functions with their
analogs among the floating-point operators, such as floating-point overflow,
x/0, or 0/0.

An exception is any case where somebody would take exception to the prescribed
default.  That's why inexact is an exception in IEEE arithmetic:  the first
rounding error, like the first glass of beer, may be the fatal step toward
a path of degradation and ruin.  Maybe, but probably not, so the default is
to record the event and continue.  Underflow is similar - the significance
depends on the context; UCSD Pascal on the Apple-][ offered you a chance
to press the space bar before it rebooted, to save you from a dangerous
loss of accuracy, but few users appreciated that.  
Overflow, division by zero,
and even invalid exceptions have the same property - the significance
can't be determined in isolation.  Since it's very difficult to 
restart after a signal or undo an error message, nonstop is the default
with these other alternatives available to the programmer to specify.