[std-interval] interval(NaN)

[Dr John Pryce]

Guillaume, George and all

At 16:07 16/09/06, Guillaume Melquiond wrote:
>Le samedi 16 septembre 2006 à 08:13 -0500, George Corliss a écrit :
>[...]
>(John's insertion of George's text:)
>>You are asserting that "undefined" is STRONGER than "implementation-defined"
>>in the sense that "undefined" is intended to forbid use.  It is a big sign,
>>"DON'T GO THERE."  That certainly helps me understand why you have argued
>>FOR "undefined" situations.
>
> > Do you expect undefined situations to be flagged by compilers? If so,
> > interval(NaN,NaN) requires a run-time check, 
> and a run-time error message is
> > similar to raising an exception or logging. Is it normal practice in
> > standard-writing that behavior in "undefined" cases is undefined, but we
> > hope that compilers will be as helpful in flagging them as they can
> > reasonably be? Where "reasonable" is the choice of the compiler writer?
>[...]
>
> > Do I understand you correctly?
>
>Yes, you understand me correctly. ... Whenever 
>the word "undefined" is encountered, C++ 
>programmers have to read "Don't even try to do it!"...

For the record this is what the draft C++ standard (2006/10/19) says:

>1.3.13 undefined behavior [defns.undefined]
>behavior, such as might arise upon use of an 
>erroneous program construct or erroneous data, 
>for which this International Standard imposes no 
>requirements. Undefined behavior may also be 
>expected when this International Standard omits
>the description of any explicit definition of behavior.

Guillaume, I think I understand your reasoning. 
But does not interval computation requires a uniquely precise specification?

Each atomic interval operation in a correct 
interval computation is one step in a 
mathematical proof - of a specialized and in a 
sense boring sort, but one capable of critical 
real-world consequences. Typically
   Given:
     Inputs x1, x2, ... (with that physical meaning) lie in those numeric
     intervals.

    ... sequence of elementary interval calculations ...

   Result: EITHER
     Outputs y1, y2, ... (with this physical meaning) lie in these numeric
     intervals.
     QED.
   OR
     I couldn't solve this problem.
     (Termination by an exception, or returning 
some "NaI"s, are ways to say this.)

Each elementary interval calculation is justified 
by some mathematical result - most of them fairly 
shallow, but sometimes a profound one as in the 
appeal to a fixed-point theorem, central in the 
solution of differential equation systems. If 
EVEN ONE STEP in this chain breaks down, the whole proof breaks down.

Leaving points "undefined" in the standard can
  - make the proof impossible to carry out, if an implementation also
    leaves it undefined; or
  - make a proof valid on one platform, but invalid on another platform
    where documented but different implementation decisions have been made.

Some "undefined"s don't matter: whether printed 
output shows ".123" or "0.123" won't affect a 
proof that two robot arms won't collide during some manipulation.

Others can be crucial. I feel this is especially 
so for constructors, which are the dragons that 
guard the gates to the magic kingdoms definedy classes.

You have written
>Whenever the word "undefined" is encountered, 
>C++ programmers have to read "Don't even try to do it!".
Suppose the result of executing something like
    x = interval(3,NaN);
is "undefined" by the standard. As we all agree, 
in general only run time checks can detect 
whether such a construct will occur in a given 
program execution. Therefore the only way to make 
the "Interval Proof" embodied by our program a 
valid proof, is one or more of these:

(a) Put the burden "Don't even try to do it!" on 
the programmer, to make run time checks on all 
arguments to interval constructors that might be NaN.

(b) Make the constructors do the run time checks, 
and throw an exception or propagate NaI, when finding a NaN input.

As I see it, the aim is to make the system 
DIAGNOSE a place where a programmer's "Interval 
Proof" is almost certainly defective and do its 
best to make her think about what is wrong. There 
may exist algorithms where interval(NaN) 
returning empty (or whole) doesn't invalidate the 
"Proof", but most algorithms will be so 
invalidated. I agree with George's view that "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."

Guillume also wrote
>As for detecting the erroneous conditions at run-time ... I don't expect them
>to be checked by default, as this incurs a performance penalty.

It seems to me that when one is creating a proof, 
this is not acceptable. The remark of the great Tony Hoare
   "Turning off runtime checks for production 
runs is like a yachtsman who wears
   a life jacket while training on land and discards it when he goes to sea."
seem to apply with much greater force to interval computation.

Please show me why I am wrong here.

Best regards

John
Dr John and Mrs Kate Pryce
142 Kingshill Rd
Swindon, Wiltshire SN1 4LW
UK
Tel (+44)1793-331062