# [std-interval] More on interval computations as proofs

Dr John Pryce j.d.pryce at ntlworld.com
Sat Oct 7 18:00:01 PDT 2006

```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
>   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.

- 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

```