X3J3 97-141
Page 1 of 1
Date: February 13, 1997
To: X3J3
From: /hpc
Subject: Interval Intrinsics (exceptions)
For every intrinsic function, we need to have an operational definition of the domain, and a standard way to
provide a standard conforming result. Historically, we have left this to the realm of general understanding.
So, for example, SQRT(-1.) is left to a mathematical definition which is either an error (non-standard
conforming) or on IEEE processors it is defined in the IEEE sense. Similarly we need to know what should
SQRT(x) return when x is an interval [-1.,1.]?
After enough subgroup time (in between meetings, and at this meeting) it has been agreed that what is
needed is an "IEEE TR-like" approach. There shall be a way for a user to inform the processor that this should
be treated as a runtime error, or to continue. That the user shall have a way to discover if such an error
occurred. Such discovery is often called retrospective.
Discussion:
For cases such as SQRT([-1,1]), one may wish to think of there being a true answer in the middle, that is 0,
with an uncertainty of 1. SQRT(0) is well defined, and is 0. Similarly for any true value greater than 0. Ex
post facto we can consider the negative values as having been overestimates of the lower bound (that is
broader than was necessary, or even useful). So the function should compute as if the interval were
SQRT([0,1]). There are many situations where this is the appropriate result and there is a camp which feels
that this is the appropriate definition.
Of course, there is another way of handling the same situation. The true value could actually be -.00001,
and therefore the appropriate result should be an error condition. There are situations where this is precisely
what a sophisticated user would want (or a naïve one for that matter :>).
There is a difference in category when the entire interval is outside the definitional domain. SQRT([-2.,-1]).
Everyone can agree that this is an error, in the same sense that SQRT(-1) is an error.
Thus there are two kinds of interval "exceptions". For want of better terms these may be called soft and
hard exceptions.
Proposal Outline:
Interval exceptions, along the lines of IEEE exceptions are defined. Think of these interval status flags as
parallel to the IEEE exceptions. But where there is one bit for IEEE there are two bits for intervals. This is
not a complete proposal, nor should it be inferred that all IEEE flags are intended to be replicated. Nor that
we need to provide quite the same level of flexibility. Our current thinking is that all interval processors
shall be required to support these flags and to support halting. Unlike the IEEE situation, there is neither
existing practice nor compelling hardware arguments to justify the extra complexity for users to complicate
their codes with tons of conditional logic.
Exception flags are sticky flags, whose value is initially clear. A processor shall provide a halting mode,
which is imprecise. The initial halting mode is halting (both soft and hard). Users must employ
INTERVAL_SET_HALTING_MODE to establish nonstop behavior. Halting shall be controlled separately
for hard and soft errors. The exception flags may be cleared by the user, stored by the user, etc. paralleling
the IEEE_GET and SET elemental subroutines.