(j3.2006) F03/0121, was Re: Interp letter ballot #25

[Malcolm Cohen]

Van Snyder wrote:
>---  -N-  F03/0121   Precise FP semantics of the REAL intrinsic
>
>            The answer to this interpretation is inconsistent with
>            13.7.1p2, including as amended by F08/0008: "A program shall
>            not invoke an intrinsic procedure under circumstances where a
>            value to be assigned to a subroutine argument or returned as a
>            function result is not representable by objects of the
>            specified type and type parameters."  This interpretation
>            permits REAL(0.1d0,kind(1.0e0)) to return a value that is not
>            representable as default real.

I am doubtful of this reasoning, but in any case I don't see how the answer is 
inconsistent with 13.7.1p2.  The quote says "A program shall not invoke" i.e. 
the program is not standard-conforming.  That is even less helpful to the user 
than what we are actually saying!

In any case 13.7.1p2 is known to be broken...

...oh and it's quite easy for REAL to return something "not representable" in at 
least some floating-point arithmetics; just give it a boz with a bit pattern 
that is not possible (IEEE arithmetic makes all bit patterns meaningful, but 
other arithmetics do not always do that).

>The caveat in 7.1.5.2.4p3 that "mathematically
>            equivalent expressions of numeric type may produce different
>            computational results" does not include permission to produce
>            a value that is not a member of the set of valid values for
>            the type and type parameters of that result.

Nonsense.  The phrase "mathematically equivalent" has no requirement not to 
produce a result that is in the "set of valid values for the type etc.", in fact 
the "different computational results" would lead one to think the exact opposite 
of this assertion.

> The only reason ever to invoke the REAL intrinsic
>            function with a real argument is to provide a result value of
>            the specified kind.

As is clear in previous Fortran standards where it states that the "identify 
transformation" version of REAL is intended to force rounding to storage format.

Oh wait, no they don't.  Sounds like a retrospective "new feature" to me!

Much as I agree with the assertion that it is easy to guess that someone writing 
REAL(x,KIND(x)) might want to round X to storage format, that is not what the 
standard says.  In fact since "REAL(X,KIND(X))" is mathematically equivalent to 
"(X)", the contrary behaviour (i.e. not rounding) is quite understandable.  I 
would be very surprised if "(X)" were supposed to round to storage format, this 
would have huge performance implications on some platforms.

Just because the identity REAL transformation is on-the-face-of-it useless 
doesn't mean we should dream up semantics that might be useful, at least not in 
an interp.  The identity assignment "X = X" is also on-the-face-of-it useless, 
but that doesn't mean it would be a good idea for it to do something "clever".

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.