(j3.2006) Interval arithmetic

Van Snyder Van.Snyder
Thu Mar 19 19:51:42 EDT 2009

I think I've narrowed down the problem that affects software
implementations of interval arithmetic, or program-specified rounding in

The citations in C14 and 754 that Malcolm provided do not do the trick
because they address events without considering the relationship between
them, and therefore don't address the cause of the problem.

The problem is ones interpretation of how interpretation f95/000104
affects f95/f03:2.3.4 or 09-007:2.3.5 (and you thought second-order
effects weren't important):

"... the effect of execution is as if the executable constructs are
executed in the order in which they appear...."

Interp f95/000104 can be read to imply that 2.3.4 (2.3.5) means "except
that the processor can use whatever precision it wants whenever it wants
for as long as it wants" because it says, without qualification:

"The processor is therefore free to use different precision for
intermediate real calculations."

One might argue "but an interpretation can't change the meaning of a
part of the standard it doesn't even mention, and especially not without
editing something."  Well, I think it can, if we're not extremely
careful about the wording of answers that are "only" clarifications, and
we were perhaps not quite careful enough in answering f95/000104.

If we were to revisit f95/000104 and add "unless doing so violates the
requirements of subclause [f95:]2.3.4" (or the equivalent subclause of
whatever standard we choose to apply it to) after "calculations", the
problem would appear to be be solved.

It wouldn't hurt to put a note in 09-007:7.1.9 that a processor can use
a representation having higher precision than implied by the kind
specified therein only if doing so does not affect the "as if"
requirement of 2.3.5.

It wouldn't hurt to put a note in the description of
IEEE_SET_ROUNDING_MODE that carrying results of higher precision than
implied by the kind specified by f95:7.1.4 (09-007:7.1.9) across a
change in rounding mode, and then rounding them, might violate the
requirements of that subclause.

I think every standard since Fortran 90 _does_ effectively allow
inter-statement optimization, since subclause 2.3.4 (now 2.3.5) says "as
if."  We just have to be careful not to allow any loopholes in the "as
if."  It wouldn't hurt to put a note in 2.3.5 to this effect.

1.4(6) should probably be re-examined, since the standard now does
specify the method (at least methods to specify the direction) of

More information about the J3 mailing list