Questions about Expectations about Interval Exceptions

[David G Hough at validgh]

     I'm curious about the programs that have been written to exploit various
systems of interval arithmetic - what expectations about exceptional cases
were built into these programs?  The context is an attempt to extend the non-
stop exception handling policy of IEEE 754 point arithmetic to intervals with
IEEE 754 endpoints.

     One point of view is that existing programs typically rely on exception
handling working in certain ways, and another is that existing programs are
typically coded defensively to avoid depending on specific exception handling.
Although interval arithmetic programs are hardly portable in the usual sense
because there are no language standards for expressing them, one would not
like to gratuitously invalidate the logic embodied in existing programs if a
consensus practice were discernible.

     In IEEE 754 point arithmetic, by default invalid exceptions like 0/0 and
sqrt(-1) produce NaN - Not a Number - and execution proceeds.   Status flags
are also set, that can be interrogated within the program, and in addition, in
most implementations the programmer can specify that certain exceptions ter-
minate execution.    The methods of interrogating flags and enabling termina-
tions were not standardized by languages until recently, and that's one of the
reasons that nonstop exception handling was specified as default in IEEE 754
twenty years ago.   Although it was and is usually a good idea to avoid 0/0
and sqrt(-1), IEEE 754 takes pains to minimize the chance that such exceptions
would produce invalid results that look valid.

     A particular IEEE 754 point NaN result might be thought about in various
ways - as an Error, as an Empty set (no such number exists), as some unknown
or non-unique real number among all the real numbers (R) or among all the real
numbers extended by affine +inf and -inf (R*), or as some unknown or non-
unique complex number among all the complex numbers (C) or among all the com-
plex numbers extended by projective inf (C*).  Which interpretation makes
sense in a particular situation depends on the larger context and is not known
to the arithmetic.   In many cases these different interpretations logically
propagate the same way, so the distinctions seldom matter.

     Note that the Empty set, R, R*, C, C* are all intervals, and so, in
interval arithmetic, their propagation is not the same, and it begins to
matter which is chosen as the default result for each specific exception.
Even in real interval arithmetic, special representations could be constructed
for R*, C, or C*, if that were deemed useful.

     Thus, cases could be made to interpret the default real interval result
for 0/0 or [0,0]/[0,0] as

Error = NaI = Not an Interval
     because 0/0 might be thought of as an error,

Empty because there isn't a real number defined to be the result of 0/0,

R    because any real number z satisfies 0 * z = 0.

     Considering a more elaborate case, [0,1]/[0,1], which might be thought of
as containing 0/0, one could plausibly argue for any of the foregoing, and in
addition

R*   or more tightly (-inf, +inf], because in addition to R for 0/0, 1/0 =
     +inf should be included,

[0,+inf]
     because since [0,1] contains no negative numbers, the ratio [0,1]/[0,1]
     should contain no negative numbers.

     As a third example, consider sqrt([-1,d]) for 0 < d << 1.   In this case
the interval is mostly negative but has some positive numbers.  Plausible
arguments might be made for

Error = NaI = Not an Interval
     because sqrt(-1) might be thought of as an error,

Empty because there isn't a real number defined to be the result of sqrt(-1),

[0,sqrt(d)]
     because sqrt is only defined over real operands and operands outside its
     domain can be ignored - since in a valid interval program, negative
     operands to sqrt can only arise due to roundoff or due to untight inter-
     val expression evaluations of expressions that should be non-negative,
     either of which can be ignored,

C    because the complex numbers include all the possible results of sqrt of
     negative intervals - in a real interval system, it is not possible to
     represent the union of [0,sqrt(d)] and [0,1]*i, but a special representa-
     tion for C would at least contain that union.

     My purpose in this note is NOT to argue about which of these various
choices is the "correct" nonstop default choice - that is a complicated issue
which has been argued from many different directions, as I've tried to indi-
cate above.  My purpose is to inquire whether the plethora of contradictory
arguments I've hinted at, plus the possibility that existing implementations
1) might silently return incorrect results, or 2) might abruptly and uncondi-
tionally terminate in the event of any of these exceptions, have had the
effect that most existing substantial interval application programs have been
written to avoid these situations entirely.

     So persons who have written such programs are welcome to comment to this
mailing list.    Did you try to stay within the real domain by programming
techniques such as -

1)   removing zero points from interval divisors, in order to handle them spe-
     cially, and so avoid division by intervals containing zero,

2)   avoiding sqrt(-1), log(-1), asin(2), and the like, by proving analyti-
     cally that interval operands to such functions would always be valid, or
     by explicitly discarding (and thus ignoring) out-of-domain parts of
     interval operands to such functions?

     Or did you rely on specific exception handling behavior in the implemen-
tations you programmed for?  Even more interesting would be cases, if any
exist, of programming intended to be "portable" in some sense across different
styles of interval implementations.



<PRE>