(j3.2006) Interval arithmetic

Bill Long longb at cray.com
Thu Mar 12 18:30:48 EDT 2009



Van Snyder wrote:
> As a consequence of my involvement with P1788, I have concluded that it
> is impossible in general to provide reliable interval arithmetic with
> other than an intrinsic type.
>
> The killer is register spill.  When a compiler has a value in a register
> that is wider than the memory representation of that variable, and needs
> the register for other purposes, it generates spill code.  Storing from
> registers to memory rounds (or, worse, truncates).  

Not on any modern processor / ABI that I know of.  This is a relic of 
legacy Intel processors, and does not seem relevant to a future standard.



> If intervals are not
> intrinsic types, the compiler can't know how to round the high-precision
> register to a lower-precision memory representation.  


But if intervals are represented as structures, certainly the components 
are of intrinsic type and the compiler knows how to deal with them.  
Again, the lower precision memory representation is a relic, but any 
argument about intrinsic versus defined types seems to be outside the 
area of "impossible to provide reliable" operations.


> Ensuring that the
> compiler respects the current rounding mode when it spills (I have heard
> that some version of gcc did not) isn't enough, because it's impossible
> for the program to know when the spill will take place, and set the
> rounding mode appropriately.
>
> Attributes for variables that say "always round thus when storing this
> into memory" would seem to solve the problem, but it doesn't tackle
> anonymous temporaries.
>
> That's not to say that intrinsic interval arithmetic should therefore
> necessarily be a part of a revision of Fortran in the immediate future.
> Rather, it demonstrates that our hope in 2003 that we could cater for it
> by providing adequate facilities to implement it using functions and
> defined operations was a fool's errand.
>   

I see no evidence of that. The only deficiency in the defined type 
approach is that (some) compilers might not generate code that is as 
efficient as for an intrinsic type.  I strongly suspect any intrinsic 
type spec would at least initially be implemented as a derived type 
internally, and thus there would be no difference at all.

Cheers,
Bill



-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            



More information about the J3 mailing list