(j3.2006) Interval arithmetic

[Van Snyder]

On Wed, 2009-03-18 at 22:59 -0700, Malcolm Cohen wrote:
> AND IN ANY CASE, you claimed impossibility.  That would seem to have 
> been a gross exaggeration

I didn't claim impossibility.  I claimed impossibility unless heroic
measures were taken, and I listed those.

1.  The standard provides an intrinsic type, about which Malcolm
quibbled that a type the compiler understands, intrinsic or not, would
work.

2.  The standard requires the processor to respect the type and kind
specified by the subclause entitled "Type, type parameters, and shape of
an expression," (f95:7.1.4 or 09-007:7.1.9), at least for values and
function results that are carried from one statement to another in other
than the precision implied by the type and kind specified in that
subclause.

3.  The standard prohibits the processor from carrying values in a
precision other than that specified by f95:7.1.4 or 09-007:7.1.9 from
their point of creation across a change in rounding mode without first
rounding them to the precision implied by the kind specified in that
subclause.  If the program changes the rounding mode by a method the
processor does not understand, this doesn't work.

4.  The standard provides an attribute for variables that specifies the
rounding mode to use when values of higher precision are assigned to
them.  This actually isn't a complete solution, since it doesn't apply
to anonymous temps arising from common subexpression elimination if they
stay in registers for a while, and are later rounded into anonymous
variables of lower precision after a change of rounding mode.

5.  The program stores intermediate results into volatile variables.

F95 didn't provide 1, 4 or 5, and 4 doesn't work completely anyway.  F95
didn't understand changes in rounding mode so 3 wouldn't work.  Interp
f95/000104 said 2 isn't required.  So programs had to round explicitly
with expressions like max(tiny,top+abs(top)*epsilon).  One of our
excuses for not doing interval arithmetic in f03 was that the IEEE
modules provide adequate support.  If interp f95/000104 applies to f03
(but Malcolm says it doesn't), the only way that's true (from the point
of view of the standard, not the occasional processor that does item 3
above even though the standard doesn't require it) is if programs that
care about rounding (or anything else related to the precision implied
by the kind of a value) is to store intermediate results into volatile
variables.