(j3.2006) Liaison to IFIP WG 2.5

William B. Clodius wclodius
Thu Aug 23 00:51:34 EDT 2007

On Aug 22, 2007, at 2:35 PM, Andy Vaught wrote:

> On Wed, 22 Aug 2007, Van Snyder wrote:
>> On Wed, 2007-08-22 at 19:59 +0100, Lawrie Schonfelder wrote:
>>> I thought intervals were about accuracy critical not performance
>>> critical!
>> In many applications, if performance costs 100 times as much, accuracy
>> will be reluctantly sacrificed.  Ultimately, the scientists will blame
>> the software engineer for the situation.
>> And interval arithmetic isn't just about accuracy.  Some algorithms 
>> are
>> not guaranteed to work, or are impossible altogether, in point
>> arithmetic, while they are guaranteed to work in interval arithmetic.
>> The poster child for this is global minimization.
>   While you're arguing about the goodness of interval arithmetic, I 
> still
> don't see the reason why it should be part of standard fortran.  People
> have written interval arithmetic packages using derived types and 
> operator
> overloading.  As far as I can tell, the code ultimately generated 
> would be
> pretty much the same either way, particularly if the compiler is clever
> with inlining.
> <snip>

No, for several reasons, some intrinsic to the language, some the 
characteristics of the language's implementations. The language is 
awkward for specifying the desired semantics as it is looser in 
specifying the semantics of floating point operations than interval 
arithmetic desires. If the intervals are to be minimized temporaries 
need to be maintained at as high a precision as possible as long as 
possible. Maintaining this precision is further complicated by 
Fortran's neglect of result type in generic resolutions. The effect of 
parentheses etc., on the distributive properties of Fortran's floating 
point  math, also makes it awkward to write optimal interval arithmetic 

As to the implementations, the optimal tradeoff between branches and 
explicit arithmetic operations will be processor specific. The larger 
number of operations involving the same values, in interval arithmetic 
compared with normal arithmetic, also increases register pressure.  The 
raw source code will have explicit changes in the rounding modes of the 
processor. These changes in mode correspond to changes in state that 
normally inhibit optimization, i.e., drain pipelines. In principle the 
order of register loads can be changed in coordination with the 
rounding modes and maintain the desired semantics, but I suspect the 
fraction of code that dynamically changes rounding mode is so small 
that compiler writers don't implement these optimizations. Even if they 
do implement these optimizations, it is likely to be in a general form 
that approximately solves the combined register/rounding mode pressure 
by a metric different from what the interval arithmetic people consider 
ideal. It will not (significantly) consider maintaining precision, and 
it will not recognize idioms specific to interval arithmetic that allow 
higher optimization.
William Clodius

More information about the J3 mailing list