Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: <50500166@uxe.cso.uiuc.edu>
Date: 11 Nov 89 01:32:08 GMT
References: <7563@xenna.Xylogics.COM>
Lines: 76
Nf-ID: #R:xenna.Xylogics.COM:7563:uxe.cso.uiuc.edu:50500166:000:4240
Nf-From: uxe.cso.uiuc.edu!hirchert    Nov 10 11:10:00 1989


Steve Correll (sjc@key.COM) writes:
...
>1. Using context doesn't work in examples like "CALL XYZ(3.5)".
>
>  Until you start using modules, the compiler cannot know the type of the dummy
>  argument. On most machines, a real/doubleprecision mismatch gives a very
>  wrong number. (An exception is the Vax, where the first half of the preferred
>  doubleprecision format happens to match the bit layout of the real format.
>  Thus, with help from little-endian addressing, a real/doubleprecision type
>  mismatch may merely degrade precision. This is often a shock when porting VMS
>  applications to other machines.)

One slight correction: In Fortran 8x, the necessary context information could
also come from a procedure interface block, which could have been written
explicitly in the caller or provided via an INCLUDE statement.  (I would agree,
however, that using modules would be a more convenient way of providing the
context information.)

BTW, there's a lot of big-endian computers (e.g., IBM mainframes) that have
the same property as you ascribe to the VAX above.

>2. Another alternative mentioned earlier, the PARAMETER statement, doesn't
>  solve the problem either. In the following example (please correct me if I'm
>  wrong) the standard permits the compiler to convert "1e50" from text to real
>  and then to doubleprecision, possibly overflowing during the intermediate
>  step. When you change REAL to DOUBLEPRECISION in IMPLICIT statements, you
>  still need to change "e" to "d" in the exponents in PARAMETER statements.
>
>	implicit doubleprecision (d)
>	parameter (d = 1e50)

Half right.  The trick is to use a D exponent in the first place.  If the
constant being defined is of type REAL, it will converted.  If it is of type
DOUBLE PRECISION, you've supplied full accuracy.

>3. For many people, who simply want to change REAL to DOUBLEPRECISION globally
>  because (for example) REAL on the Cray gives them the same results as
>  DOUBLEPRECISION on the Vax, somehow extending the IMPLICIT statement to
>  constants would work well. Unfortunately, that's not a particularly general
>  or powerful approach, and therefore not attractive to a standards committee.
>  The F88 approach solves the problem too, as soon as we all finish editing all
>  our sources to put "_my_precision" after all the constants.:-) Unfortunately,
>  it's going to be hard to find a missing "_my_precision" in a large program.

I agree.  That's one reason I like Gary Campbell's approach.

>4. My experience with PL/I says that if the language designer lets the
>  programmer specify the number of decimal digits of precision, the law of
>  unintended consequences takes effect, and you get exactly the opposite of
>  what you wanted. Very few PL/I programs say "float bin(my_precision)".  Most
>  say "float bin(6)" or "float bin(5)" or whatever the programmer memorized as
>  an idiom for "single precision" when s/he first learned the language. If
>  several programmers work on the same source, it probably uses "6" in some
>  places and "5" in others. It's actually riskier to change precision with a
>  text editor than in Fortran 77, because you can be tripped up by a single "5"
>  that should have been a "6".
>
>  In this, the current F88 draft improves on the previous one. Because you must
>  use an intrinsic to obtain precision in terms of digits, you are more likely
>  to store the precision in a parameter and use that instead of repeating the
>  number of digits (perhaps inconsistently) throughout the program.
>
>  It's still difficult to ensure that you haven't omitted a "KIND=" after a
>  REAL somewhere in a large program. The Pascal "type my_precison = real"
>  facility works better, since it's easy to make sure that un-parameterized
>  precision doesn't creep into your source by accident: use an editor to check
>  that the word "real" appears only once. A similar facility vanished from F88,
>  perhaps due to complaints about complexity.

With the editors I use, it wouldn't be that hard to search for REAL followed
by a character other than "(", but not all editors allow you to search for
regular expressions.

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