Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN 8X PRECISION
Message-ID: <50500165@uxe.cso.uiuc.edu>
Date: 10 Nov 89 01:33:32 GMT
References: <7563@xenna.Xylogics.COM>
Lines: 90
Nf-ID: #R:xenna.Xylogics.COM:7563:uxe.cso.uiuc.edu:50500165:000:3889
Nf-From: uxe.cso.uiuc.edu!hirchert    Nov  9 10:38:00 1989


Rich Bleikamp (bleikamp@convex.UUCP) writes:
...
>But what do you do in a more complicated expression?  For example :
>
>   REAL A
>   DOUBLE PRECISION X
>
>   X = X + A + 3.14159 - 2.71828/2.0
>
>   Some users will want all these constants to be D.P.

I haven't seen Gary Cambell's proposal, so this might not be his answer, but
it is the one I would suggest.  According to the standard, the above statement
parses as

    X = ((X + A) + 3.14159) - (2.71828/2.0)

    X is double precisiona and A is real, so (X + A) is double precision.

    3.14159 is a constant, so it takes on the precision of the of the other
    argument of the binary operator (X + A) and is double precision.

    2.71828 and 2.0 are both constants, so the assignment of precision is
    pushed one level up the parse tree.  ((X + A) + 3.14159) is double
    precision, so the constant expression (2.71828/2.0) is made double
    precision, so both 2.71828 and 2.0 are made double precision.

If the original statement had been written as

    X = X + (A + 3.14159 - 2.71828/2.0)

    all the constants would have been single precision and only the final
    parenthesized expression would have been converted to double precision.

If it had been written as

    X = X + (A + 3.14159) - 2.71828/2.0

    then 3.14159 would have been single precision, but the other two constants
    would have been double precision.

>   Should commutive operations be handled special?  Use the "nearest" neighbor?
>   Or perhaps the destination?   None of these is particularily great.

Nothing special for commutative operators.  This is the "nearest" neighbor
in parse terms.  Destination would be relevant only if the entire right
hand side were a constant expression, as in

    X = 3.14159 - 2.71828/2.0

There are a few cases where no context is available, e.g.

    CALL MYSUB(3.14159)

    In this case, 3.14159 would have default precision in order to be
    compatible with FORTRAN 77.

I don't know whether Gary would retain the notation 0.1_MYKIND for special
cases or just depend on REAL(0.1,MYKIND).  (I would lean towards the latter
because I don't think those special cases would come up often enough to
justify reserving a special syntax for them.)

One way to look at these rules is that when the kind of a constant expression
is coerced implicitly (by being combined with another operand or by being
assigned) or explicitly (by use of the REAL intrinsic), then the constant
expression is originally evaluated in the destination kind.

>   I'd prefer a vendor supplied compiler option to force all literals
>   (and optionally REAL variables) to be double precision.  Unfortunately,
>   this is not going to make it into the standard.  Some way to coerce
>   all constants and variables of a particular type to a different "kind"
>   without resorting to PARAMTER statements, bizarre syntax, etc. is needed,
>   but doesn't seem to fit into the language.  Perhaps a "DEFAULT_REAL_KIND"
>   which can be user specified (outside the language, via compiler options)
>   should be a capability mandated by the standard.  Although this is not
>   very good software eng., it will do the most to promote portability of
>   existing programs.

The coercion approach that Gary is suggesting _does_ fit into the language.
The problem that killed this approach when it was suggested before is that
FORTRAN 77 explicitly requires constants with the same form to have the same
value.  I believe that this requirement has no "teeth" in these cases because
there was no requirement that coercions of the same value should produce the
same value, but this argument is hard to sell to the full committee.  I hope
Gary is more successful than I was because I believe it is a much cleaner
approach than what is currently in the draft.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications