[std-interval] More on interval computations as proofs

[Sylvain Pion]

Steve Clamage wrote:
>  >>Dr John Pryce <j.d.pryce at ntlworld.com> writes:
>  >
>  > Throwing exceptions was shot down for speed and
>  > stack-destroying reasons, ...
> 
> What is the objection to the stack-destroying property of exceptions?

Algorithms that only need the basic inclusion property of interval
arithmetic, but do not need to detect discontinuities, would be hurt
by such exceptions.

Algorithms that need to detect discontinuities, may still be interested
in the return value of a function representing the evaluation of a
function.  (I admit I am not an expert on such usages of IA, but this
is what I understood from the opinions expressed here.)

> You can choose to catch the exception where ever you are prepared to 
> deal with it. Only the stack frames between the throw point and the 
> catch point are lost.

Sure, but if you have a block of calls to operator/(), sqrt()...  you 
probably don't want to protect each of them by a surrounding try/catch
block.

One may argue that calling operator/ should be protected before hand,
by a test wheter 0 is in the divisor interval, and similar for other
functions.  I don't know if this would be acceptable.  Maybe this is
part of what Gaby means by "rewriting for interval".

> I don't see how that situation differs from the solution using a global 
> flag. The stack frames between the point of error and the point where 
> you check the flag are still lost.

I don't follow.  Affecting a value to a global flag does not destroy
anything.  Maybe considering examples would make things clearer:

interval f(interval a, interval b, interval c, interval d)
{
   return sqrt(a+b) + sqrt(c+d);
}

If sqrt() throws, then I cannot get the return value of f.

-- 
Sylvain