NCEG Exceptions - a way of handling the defining of the exception handling definition
David Hough
dgh
Thu Mar 1 20:28:37 PST 1990
Possibly to be merged with the NCEG Operators proposal circulated earlier.
Sun engineering people can get a formatted copy of this document via
tbl ~dgh/memo/nceg.operators | eqn | troff -ms
NCEG Proposal - Exception Handling
The following outlines a way of describing exceptions in an NCEG report
that encompasses most existing implementations without too much work, while
pointing out preferable alternatives. I'm interested in your comments as to
whether this trend of thinking is worth pursuing. SHALL constrains all NCEG
implementations, SHOULD is a recommendation.
4.1.7 Floating-Point Exceptions
Operators and functions which take floating-point operands or produce
floating-point results may produce a variety of exceptions on different sys-
tems. Some of these are inherent in the underlying mathematical functions of
real variables; others are consequences of the finiteness of the set of
representable floating-point numbers. In the following, "functions" and
"operators" are interchangeable; the distinction between functions and opera-
tors is important in language definition and compiler implementation but both
represent mathematical functions.
4.1.7.1 - Exceptions arising from mathematical functions
These exceptions must be dealt with in defining mathematical functions,
independent of any consideration of computers.
SINGULARITY/POLE/DIVISION-BY-ZERO exception. If division is viewed as a
function of finite real operands producing a finite real result, then an
operation like 1/0 has no meaning. However the real number system can be
extended by adding an unsigned point at infinity or by adding two signed
infinities; then it may be meaningful to assign infinite results to operations
like 1/0. Thus a SINGULARITY exception arises when an infinite result is
assigned to a function of finite real operands. Since the meaningfulness of
such assignment varies among applications, an exception is appropriate to
alert applications for which such assignments are inappropriate and on systems
or for types for which such assignments are impossible.
From the point of view of traditional complex analysis, the singularity
exceptions encompass poles like 1/0 and logarithmic singularities like log(0),
but not removable or essential singularities. Applications like continued
fractions are common enough to suggest that singularity exceptions be dis-
tinguished from the following:
INVALID/DOMAIN exception. In contrast to the foregoing, 0/0 can't be
assigned a value consistently over broad classes of applications. If 0/0
arises as lim(x->0) f(x)/g(x), for instance, the appropriate limit depends on
f and g. Each application is a special case. Thus an INVALID (operand)
exception arises when no finite or infinite real result can be meaningfully
assigned to a function of finite or infinite real operands. Hence the real
function sqrt(-1) causes an invalid exception but a complex function would
not.
An implementation may also define invalid exceptions on attempts to use
non-numeric representations like IEEE signaling NaN or VAX reserved operand.
4.1.7.2 - Exceptions arising from finite floating-point arithmetic.
These exceptions don't occur in the context of exact mathematics but are
artifacts of finite computer number representations.
INEXACT exception. All fixed-length numeric data types can only
represent a finite number of real values. Consequently when a function com-
putes a real value that is not representable exactly must round it according
to some rule to produce a representable number and continue. Thus an INEXACT
exception arises when an unrepresentable real value is replaced by some dif-
ferent representable value.
IEEE 754 and 854 systems detect these normal inexact exceptions. There
is an implementation-defined class of "normal" rounding errors; other excep-
tions are defined for abnormal ones, which are detected on most systems:
INTEGER OVERFLOW exception.
Integer addition, subtraction, and multiplication are usually exact,
while division is expected to produce an error < 1 in absolute magnitude.
Thus an INTEGER OVERFLOW exception occurs when a larger than normal roundoff
error, >= 1 in magnitude, occurs in storing a value into an integer or
unsigned type. Many C implementations don't detect integer overflow.
FLOATING-POINT OVERFLOW exception. Every fixed-length numeric data type
has a largest finite representable value. Associated with this bound is the
possibility of unusually large errors in converting an arbitrary real value to
a floating-point representation. Thus a FLOATING-POINT OVERFLOW exception
arises when a large real value can't be stored with only normal roundoff
error.
UNDERFLOW exception. Every fixed-length numeric data type has a smallest
positive representable value different from zero. Associated with this bound
is the possibility of unusually large errors in converting an arbitrary real
value to floating-point representation. Thus an UNDERFLOW exception arises
when a small real value can't be stored with only normal roundoff error.
IEEE 754 and 854 systems detect underflow in some cases for results that
are intermediate in size between the smallest normal and smallest subnormal
values, as well as for non-zero results that round to zero.
4.1.7.3 - Exceptions arising from roundoff magnification or algorithmic limi-
tations
SVID defines exception types TLOSS and PLOSS for "total and partial loss
of significance" in results of trigonometric and bessel functions. PLOSS sig-
nifies function results that are highly sensitive to roundoff errors in the
function arguments, even though the functions themselves might be exact, and
thus is related to significance exceptions signaled on some older systems.
The ultimate source of the roundoff sensitivity is subtraction of nearly-equal
quantities, at least one of which is affected by roundoff. Thus PLOSS arises
in ordinary subtraction, in remainder-type operations like fmod(), and in
log(x) and pow(x,y) for x near 1, as well as in trigonometric argument reduc-
tion. Since roundoff and subtraction of similar quantities are endemic in
floating-point computation, the general problem of bounding roundoff requires
analytical error analysis or computational bounds using means such as interval
arithmetic. Because there is no natural boundary between normal roundoff and
PLOSS situations, NCEG implementations SHOULD avoid indicating these excep-
tions.
TLOSS signifies function results which are completely incorrect due to
algorithmic limitations. For NCEG systems, such results SHOULD be avoided by
using correct algorithms.
4.1.7.4 - Methods for handling exceptions
Systems implement a variety of exception-handling mechanisms; these are
often provided inconsistently. These include:
Ignore and continue
with a default result.
Set errno
per X3J11. Setting the global errno to EDOM is appropriate for singular-
ity and invalid exceptions, and to ERANGE is appropriate for inexact,
integer overflow, floating-point overflow, or floating-point underflow
exceptions.
Call matherr()
per SVID. matherr() is a fixed error-handling function that by default
will fix a substitute numerical value and may also print a message. User
programs may redefine matherr().
Set an accrued exception bit
per IEEE 754 or 854. The accrued exceptions may be tested for NCEG IEEE
systems by calling getfpexception().
SIGFPEgenerating a SIGFPE on the occurrence of an exception. IEEE 754 or 854
systems sometimes define SIGFPE to be their response to IEEE 754
"trapped" exceptions.
4.1.7.5 - NCEG requirements for exception handling
X3J11-defined operators such as +-*/, and algebraic functions such as
sqrt and strtod, that have floating-point operands or results SHALL handle
each exception in a uniform manner, whether the operator or function is imple-
mented in hardware or software. The handling of different exceptions need not
be uniform, however. In addition, transcendental functions SHOULD handle
exceptions other than inexact uniformly with algebraic functions and opera-
tors. How, or whether, inexact exceptions of transcendental functions are
detected is not specified for NCEG systems.
The following functions support run-time inquiries:
enum nceg handler t = { nceg ignore, nceg errno, nceg matherr,
- - - - -
nceg status, nceg sigfpe, nceg other } ;
- - -
enum nceg exception t = { nceg invalid, nceg singularity, nceg integer overflow,
- - - - - -
nceg floating overflow, nceg underflow, nceg inexact,
- - - -
nceg tloss, nceg ploss } ;
- -
nceg handler t get nceg handler ( nceg exception t ) ;
- - - - - -
int set nceg handler ( nceg exception t, nceg handler t ) ;
- - - - - -
get nceg handler() returns the current type of handling for a particular
- -
exception. set nceg handler() allows setting the handling for that exception.
- -
set nceg handler() returns 1 if the request succeeds, 0 if it fails because
- -
the implementation doesn't support that type of handling for that exception.
An implementation may support more than one type of exception handling per
exception type.
NCEG implementations of IEEE 754 and 854 SHALL handle exceptions as fol-
lows:
Exception Default Optional
invalid status sigfpe
singularity status sigfpe
integer overflow ignore ignore
floating overflow status sigfpe
underflow status sigfpe
inexact status sigfpe
tloss ignore ignore
ploss ignore ignore
Other NCEG implementations SHALL provide the same handling, except that the
defaults may be different for implementation efficiency reasons. In such
cases, the omitted IEEE-style default handling SHOULD be available as an
option.
4.1.7.6 - Catalog of mathematical exceptions for X3J11 operators and functions
Most X3J11 operators and functions may suffer from integer overflow,
floating overflow, underflow, and inexact exceptions because of inevitable
finite data representations. They SHOULD NOT suffer from tloss or ploss
exceptions. The following catalogs mathematical exceptions that may occur for
finite operands:
Operator Exception Example
/ singularity nonzero/zero
/ invalid zero/zero
atof strtod *scanf invalid atof("xyz");
acos,asin invalid argument magnitude > 1
atan2 invalid atan(0,0)
fmod invalid fmod(x,0)
log,log10 singularity log(0)
log,log10 invalid log(-1)
pow invalid pow(negative,non-integral)
pow singularity pow(zero,negative)
sqrt invalid sqrt(-1)
...table to be continued
More information about the Numeric-interest
mailing list