Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!sun-barr!newstop!sun!amdahl!key!sjc
From: sjc@key.COM (Steve Correll)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN 8X PRECISION
Message-ID: <1209@key.COM>
Date: 9 Nov 89 06:16:29 GMT
References: <7563@xenna.Xylogics.COM> <8619@microsoft.UUCP> <MCCALPIN.89Nov6204250@masig3.ocean.fsu.edu>
Organization: Key Computer Labs, Fremont, CA
Lines: 67

In article <MCCALPIN.89Nov6204250@masig3.ocean.fsu.edu>, mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes:
> I have been talking with Gary Campbell of Sun Microsystems, and his
> proposal gets to the heart of the problem.  The problem with literal
> constants is that the stupid compilers insist on assigning a precision
> to them without looking at their context.  Then the context is used
> later on to decide what conversions are required to obey the
> mixed-mode arithmetic rules...
> Examples:
> 	REAL			A, B, C
> 	DOUBLEPRECISION		X, Y, Z
> 
> 	A = 2*B			! 2 is a REAL constant by implication
> 	X = Y+3.1*Z		! 3.1 is a DOUBLEPRECISION constant

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.)

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)

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.

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.
-- 
...{sun,pyramid}!pacbell!key!sjc 				Steve Correll