[std-interval] interval(NaN)
Dr John Pryce
j.d.pryce at ntlworld.com
Mon Sep 18 00:49:55 PDT 2006
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
More information about the Std-interval
mailing list