(j3.2006) (SC22WG5.4773) [ukfortran] [Letter ballot 3 on Fortran 2008interpretations]

[Van Snyder]

On Mon, 2012-09-17 at 08:00 -0500, Bill Long wrote:
> The loophole is that the result value is vague in the definition of 
> REAL() - "processor-dependent approximation".

Regardless of how "processor-dependent approximation" is interpreted,
the result value is still required to be a member of the set of valid
values for the type and kind of the result variable.

> So, for example, REAL(X) -> x*1.2 seems legal. Stupid, but legal.
> However, this argument of "better answers", particularly in "the vast
> majority of cases", does not make sense to me.   If X is a 64-bit real
> and R8 is the kind parameter value for 64-bit reals, then REAL(X, R8)
> would have the exact same bit representation as X in any reasonable
> implementation.
> 
> I realize that there was some blather about 80-bit registers, but
> that's history, and I don't really see it coming back.  Is the whole
> goal of this interp to provide the flexibility, in the future, for
> some vendor to implement this sort of hardware again?
> 
> Furthermore, even in the face of odd hardware, if the user really
> wants to ensure that he is getting the desired 64-bit value, how,
> apart from REAL(X,R8), is this supposed to be accomplished?

This is entirely orthogonal to the original motivation for the
interpretation request.  The desire was to be able to get a default-real
value, that is, a member of the set of valid values for default real,
from a double precision argument.  Being able to do this is essential to
Kahan summation, and other methods to do arithmetic without avoidable
loss of precision.

This had been done for decades until some vendors intepreted
"processor-dependent approximation" as NOP, to make some arcane SPEC
benchmarks run faster.  Fine.  Add a compiler switch that causes that
behavior, with a caveat that it causes the processor not to conform to
the standard.