guillaume.melquiond at ens-lyon.fr
Tue Sep 19 09:14:48 PDT 2006
Le dimanche 17 septembre 2006 à 23:49 +0100, Dr John Pryce a écrit :
> Guillaume, I think I understand your reasoning.
> But does not interval computation requires a uniquely precise specification?
> 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.
Given intervals in input, the proposal guarantees that any sequence of
interval operations will lead to interval results and their properties
are perfectly defined (from an interval arithmetic point of view). This
is a strong guarantee: as long as you don't mess with the intermediate
results somehow, your "proof" holds.
Now, the proposal flags some behaviors as undefined. None of them
happens in the situation above. It can only happen when the programmer
introduces objects that are not intervals among the computations.
Moreover, note that we are talking about data that are not specified by
In addition, this does not apply to user inputs (operator>>). Their
behavior is defined whether they can or cannot parse an interval. So, in
conclusion, we are only talking about data that have been created by the
programmer and that are not specified by the Standard.
About Not-an-Interval, I think its interpretation only match
floating-point signaling NaNs, not quiet NaNs. Indeed, contrarily to
quiet NaNs, signaling NaNs cannot be generated by any floating-point
arithmetic operations. This is the same with an hypothetical
Not-an-Interval, none of the arithmetic operations of the proposal would
generate them, they can only appear at "entry-points". So there is not
much point in propagating them across every arithmetic operation. And I
don't want to have to define what would be the semantic of functions
that return bool, bool_set, and float, when they encounter such an
interval. In my opinion, the sensible solution is to have a behavior
similar to sNaN: "trapping" when they are encountering, which translates
to: throwing a C++ exception.
Now, back to the main problem. Where should the invalid floating-point
values be detected? I don't think every function should pay this (not
necessarily negligible) cost for checking the values. In particular, we
still need a way for the programmer to quickly create an interval when
the values are known to be valid. This was the point of leaving
interval(T,T) partly undefined.
So I suggest having interval(T) throw an exception , leaving all the
other functions undefined when encountering a non-finite floating-point
number. This leaves one point of disagreement between us: you want the
checking to be implicit to every functions (don't let any programming
mistake go through), while I want the checking to be explicit and
restricted to a few functions (don't pay for what you don't need). I
suggest we wait for the opinions of the other mailing-list members on
which checking policy should be chosen.
 I believe that, whenever somebody spoke about an exception-free
library, it applied to the empty set and interval inputs outside the
mathematical domains of the functions. So having an exception should
still be consistent with this paradigm, shouldn't it?
More information about the Std-interval