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

[Bill Long]

On 9/14/12 1:13 PM, Van Snyder wrote:
> On Fri, 2012-09-14 at 17:48 +0900, Malcolm Cohen wrote:
>> Van Snyder wrote:
>>> My most fundamental objection to the interpretation is that it is
>>> inconsistent with the requirements of 4.1.2, 4.2, and 13.7.2.  According
>>> to 4.1.2 and 4.2, A type is characterized by a kind type parameter.  The
>>> type and kind type parameter value together specify a set of valid
>>> values.  According to 13.7.2, a function is required to return a value
>>> that is a member of the set of valid values for the type and kind of its
>>> result.  The interpretation violates this requirement.
>>
>> That is simply not the case.  That is not what 13.7.2 says. either before or
>> after other interps changed that wording.
>
> 13.7.2 was a typo.  It ought to be 13.7.1p2.  F08/0008 replaces "outside
> the range of values representable by objects of the specified type and
> type parameters" at [325:8-9] with "not representable by objects of the
> specified type and type parameters."
>
> How can a value that does not meet the requirements of 4.1.2 and 4.2 be
> representable by an object of the specified type and type parameters?


Certainly there is no question that kind(real(x,kind=k)) == k has to be 
true.  And the type is REAL. Those are the required result 
characteristics in the definition of the REAL() intrinsic.

>
>> Furthermore, even if it did, such an interpretation of the "valid values"
>> wording would not result in "better answers" but (in the vast majority of cases)
>> worse answers, quite apart from the effects on optimisation.
>

The loophole is that the result value is vague in the definition of 
REAL() - "processor-dependent approximation".  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?

Cheers,
Bill


> If one wants a "better answer," DO NOT wrap a double-precision real with
> a REAL intrinsic with a KIND argument equal to KIND(0.0e0)!  The ONLY
> reason for the latter is because one DOES WANT (!) a value that is a
> member of the set of valid values for REAL(KIND(0.0e0)) :: ....
>
> Patient: "Doctor, it hurts when I do this!"
> Doctor:  "Don't do that!"
>
> The "performance" argument is entirely bogus, and I will continue to
> believe so until somebody shows me profiler results from a
> representative set of real applications, not artfully contrived SPEC
> benchmarks.
>
>> Cheers,
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101