[std-interval] More on interval computations as proofs

Steve Clamage Stephen.Clamage at Sun.COM
Sun Oct 8 09:20:22 PDT 2006


Sylvain Pion wrote:

> Steve Clamage wrote:
> 
>>  >>Dr John Pryce <j.d.pryce at ntlworld.com> writes:
>>  >
>>  > Throwing exceptions was shot down for speed and
>>  > stack-destroying reasons, ...
>>
> 
>> 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.

OK, I see. You don't object to the stack-destroying property, you object 
to the possible need to have try-catch blocks throughout the code.

If sqrt did not throw an exception to report an error, I suppose it 
would return some Interval equivalent of NaN. For sake of argument, 
let's call it "iNaN", since I believe this point is still under discussion.

I have no experience working with Intervals, but it is not obvious to me 
why using iNaNs is better than catching the exception at the same point 
where you would check for iNaN. In the example, if sqrt was passed an 
invalid argument, is the return value of f still interesting? And if so, 
is the result of computations using f's return value also interesting? 
If so, I take your point. If not, exceptions seem like a good error 
mechanism.

Let me suggest another straw man, taken from C++ IOstreams, which has 
has two error-reporting mechanisms.

Each stream object has a state variable with a bit for each condition of 
iterest ("EOF", "fail", and "bad" at minimum, where "bad" also implies 
"fail").  If "fail" is set, further operations are ignored until you 
explicitly clear the state. If an iostream is at EOF, input and 
forward-motion operations are ignored. A stream thus has an analogue of 
NaN-like behavior. (I am deliberately skipping some details.)

A stream object also has an exception mask whereby setting a condition 
specified by the mask throws an exception. For example, you could have a 
stream object throw an exception when an operation sets "fail", but not 
EOF. The mask can be changed dynamically. By default, the mask is clear, 
and exceptions are not thrown.

Using C++ streams, you have at least 2 options for error detection.
1. You can run though a series of operations and check the state at the 
end. If "fail" is not set, you have a valid result.
2. You can have the stream throw an exception on failure, and catch the 
exception at a point where you are able to decide what to do next.

With either detection mode, a failed operation means that no further 
input or output occurs. Without exceptions, other side effects might 
occur, like trying to use the result of a failed operation.

Whether exceptions are thrown is the property of each stream object, not 
a property of functions that act on an object. There is only one set of 
functions.

A program typically has few stream objects, whereas it could have 
millions of Interval objects. The per-object choice of exception use 
might not make sense for Intervals, but I wanted to mention the possibility.

---
Steve Clamage, stephen.clamage at sun.com


More information about the Std-interval mailing list