[std-interval] interval(NaN)

[George Corliss]

(Sorry for the premature release of a draft of this message)

I want to pick up on one of John Pryce's issues: interval(NaN)

> For instance. At present "interval(NaN)" is mandated to return empty,
> but "interval(NaN, NaN)" need not. What happens if a safety-critical
> program developed on a system where "interval(NaN, NaN)" returns
> empty is ported to one where it returns whole, or some other value,
> or raises an exception?
> 
> The vast majority of machines on which interval computation will be used are
> - IEEE-conforming;
> - used by the general scientific community, for whom portability and
>    future-proofing of code is vastly important.
> 
> On a non-IEEE machine, if interval computation is used I believe it
> will be for a specialist purpose (e.g. embedded processor in
> avionics). Portability FROM such a machine TO a different platform
> will not be so important.
> 
> The standard should respect the needs of both these types of application.
John asks that the standard specify the behavior.  I agree.  Here, I want to
think about what the behavior should BE.

First, interval(NaN) should not be used by the programmer as a means for
constructing an instance of the empty set.  There is a constructor for that,
and the internal representation of empty should be hidden from the
applications programmer.

Hence, interval(NaN) is likely to come up in a context such as
   double w, x;
   x = mess of double code which happened to result in NaN;
   y = interval(x);
   z = interval(w, x);

Alternatives:
   1. Empty
   2. Whole
   3. Exception
   4. Tag as "Not an Interval"
   5. Other?


1. Empty.  If the NaN arose as, say, SQRT(-1), then y = empty is consistent
with the exception-free operation of the proposal.  For w, I see no value
that makes sense.

2. Whole is attractive in the set sense - if there is a number y or z, they
must belong to the universal set, but set difference can lead to a
containment failure, so whole is not 100% safe.

3. We want to avoid exceptions to the extent possible.

4. Tag.  If we had a set of Boolean flags or similar associated with each
interval object, one of those bits could be turned on to represent "Not an
Interval."

The problem again is that two double word bit patterns lack the expressive
power we need.  The more of these examples I consider, the more attracted I
become to the concept of tags, as variously promoted by Kahan and by Winter.
However, many suspect a tagged implementation is slow, and we have no
experience to prove otherwise.  I favor the standard allowing tags, as I
believe it does, but it is not appropriate to require them.

I'd love to see a team develop a high-quality tagged implementation so we
could compare its performance.

Especially for interval(w, NaN), and by association also for interval(NaN),
I am reluctantly led to prefer exceptions.  If you are so badly lost that
your code is trying to form an interval, at least one of whose endpoints is
Not a Number, it is probably time to quit.

Dr. George Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee, WI 53201-1881
George.Corliss at Marquette.edu
414-288-6599 (office); 288-4400 (GasDay);
    288-6280 (Dept.); 288-5579 (fax)
Office: Haggerty Engineering 296
Www.eng.mu.edu/corlissg

The more