[std-interval] More on interval computations as proofs

[Dr John Pryce]

All

There seems a consensus, and so far no sharp opposition, that we 
should implement the DISCONT flag as a global, thread-local flag and 
accept the limitations on optimization that this entails, as per 
Sylvain's posting:

At 10:55 06/10/06, Sylvain Pion wrote:
>Anyway. Going back to the original problem, I think that rewriting the
>formulas to get sharper intervals is one thing. But rewriting to pass
>additional flag arguments to each function is not really nice.

I agree with that distinction.

>My personnal opinion here is that the speed gains here are not worth
>duplicating the interface of many functions. So, for the proposal
>right now I would go for a global (thread-local) flag. ... we need 
>to write something now.

I have a further question for you, Lawrence, if I may:
At 00:29 05/10/06, Lawrence Crowl wrote:
>Compilers tend to put functions in one of few categories:
>
>   0: The function's computation is based only on its arguments
>     and returns results only through its return value. It reads
>     no global memory (excepting unvarying tables of coefficients
>     and the like).
>   1: The function's computation is based only on its arguments,
>     but may read and write memory through pointer arguments, but
>     will not write to global variable nor read from a non-constant
>     global variable.
>   2: The function's computation is as 1, but may additionally may
>     read from global variables.
>   3: The function may do anything.

In the days when I wrote Fortran 77, globals (COMMON blocks) were 
ubiquitous. I learned a bit about the discipline of using them with 
relative safety. One paradigm is "the statistics gathering block". 
Here, a possibly large number of subroutines write data to the 
variables in the block, such as incrementing a counter each time a 
routine is called. Only one part of the program is allowed to 
initialize this block; another part reports the statistics when gathered.

DISCONT follows a similar paradigm:
- Elementary functions, used by APPFCN, may update DISCONT. They 
never initialize it. Neither they nor APPFCN may use it to affect 
their control flow.
- Only the code that calls APPFCN may initialize DISCONT and take 
action based on its value.

DISCONT behaves like a non-intervening observer sitting in at a 
meeting and reporting afterward. This seems to me to be a situation 
that is easier to optimize code for, than is Lawrence's category 1, 
and nearly as easy as category 0. Lawrence, if compilers don't 
recognize this category, why not? If they could do so, the efficiency 
objection to this type of flag falls away.

John


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