(j3.2006) Interval arithmetic

[Van Snyder]

On Tue, 2009-03-17 at 18:48 -0700, Malcolm Cohen wrote:
> I see no point in continuing a discussion with so many
> counterfactuals.  Life is too short for me to spend it repeatedly
> deconstructing the same mistakes.

Malcolm has focused on the irrelevant mistakes rather than on the real
problem.

Whether an Intel processor can or cannot represent a single-precision
value in its double-precision registers is irrelevant to this
discussion.  I have to apologize for chasing Bill's red herring.

The beginning of the problem is that interp f95/000104 explicitly allows
a many-to-one correspondence between representations on the one hand,
and values of a single type and kind on the other hand, and in
particular allows a Fortran processor to represent a value that
f95:7.1.4 says is default real using a representation having the same
precision as double precision.  The point is that the standard ALLOWS
it, not whether Intel hardware FORCES it.  The rest of the problem is
that the standard is completely silent about when the wave function of
this superposition must collapse to the single representation required
by 7.1.4.

At the instant a value is computed it can be rounded in perfectly good
conformance with 754 for the representation it has at that instant.
Since the value can have several representations, it can be put into a
different representation at a later instant, and again rounded at that
instant in perfectly good conformance with 754.

The latter instant is, however, allowed to be completely invisible to
and uncontrolled by the program.  The program can change the rounding
mode between these instants, without knowing even of the existence of
the second instant, let alone being able to, or knowing that it should,
enforce that the rounding mode at the second instant is the same as at
the first.  There is nothing in the standard that prevents these
instants from being separated by a change in rounding mode.

There are no problems for the Fortran processor to conform to 754
because 754 does not address the issue of a value in a Fortran program
having more than one representation, both conforming to 754, or of the
rounding mode being changed between the computation of a value and its
conversion to a different representation.

A processor could solve this problem by forcing values to the
representation of the kind demanded by 7.1.4 before any rounding mode
changes, but the standard does not require it.  One of the arguments
that led to the outcome of f95/000104 was that it was undesirable, on
performance grounds, to do so.  Vendors are free to pursue the SGI path
(get it out, get it fast, get it right) or the NAG path (get it right,
get it out, get it fast).  Users might not understand there are two
different paths, or that the vendor they chose followed the wrong one,
until the bridge falls down.

A program could avoid this problem by using the enormous hammer of
storing intermediate values into volatile variables before changing
rounding modes (but who knows what guarantees that provides?).

The standard could solve the problem either by requiring only one
representation for a particular type and kind, or by requiring that the
result of a computation be put into the representation of its type and
kind without any rounding mode changes intervening between those events,
or by providing an attribute for variables that allows a program to
specify how values are rounded before being stored into them.