Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!bu-cs!xylogics!uucp
From: mvs.draper.com@RELAY.CS.NET!PDM1881
Newsgroups: comp.lang.fortran
Subject: FORTRAN 8X PRECISION (MORE)
Message-ID: <7662@xenna.Xylogics.COM>
Date: 13 Nov 89 15:51:41 GMT
Sender: uucp@Xylogics.COM
Lines: 56


Let me comment on my own words, in the light what has happened since:

> For floating point, I want X3J3 to define a minimum number of decimal
> digits of precision to be delivered for an item of type REAL:  I
> suggest 10.  This number must be such that almost 60 bits are required
> to do the job.  In other words, 32 bits will not a REAL value hold.
> DOUBLE precision is defined as providing more precision than REAL.
> The new type LOW PRECISION selects a lower than REAL precision, if
> available.

Several people commented that the single precision found on IBM
mainframes, VAXes & PC's and many other 32-bit systems is valuable for
many applications.  The performance penalty on our IBM mainframe is
about 15% for going to all double, the actual precision is over 2.5
times greater, and many programmers would have no idea if they have a
precision problem or not.  However, I did not propose to eliminate
single precision, but simply to make it both (1) a compiler option, and
(2) a source change option.

However, I agree that DOUBLE PRECISION most often means about 64 bits of
data, roughly 15 decimal digits of precision.  I would be willing to
accept that as a definition.  REAL would mean less precision if
available, and a new EXTENDED PRECISION data type would be added.  The
compilers on the large word systems would then need to have an option to
"do it the old way," meaning, compile DOUBLE as EXTENDED.  (I don't use
any such systems, but I think that's CDC, Cray, etc.)

My claim to solving the IMPLICIT problem for constants has been refuted.
Extending the syntax of IMPLICIT seems attractive.  However, I am a
great fan of IMPLICIT NONE, and I'd like to explore ways of solving this
problem without extending IMPLICIT.

One argument was that the compiler has to know what precision is needed,
and should simply compile it.  This was refuted by the subroutine CALL
problem.  Then it was pointed out that this is solved by INTERFACE
blocks in 8x.  Well, I don't want interface blocks, but I agree that
this is the right approach.  What I would prefer, is to extend the
syntax of the EXTERNAL statement, for example, a routine calling

  REAL FUNCTION FUN (X, I)

could contain

  REAL     FUN
  EXTERNAL FUN (REAL, INTEGER)

Furthermore, such statements could be included in the function (or
subroutine) itself, for the compiler to verify.

I greatly prefer extensions to the existing structure of the language,
to the kinds of changes proposed by X3J3.

Pete Matthews
Draper Laboratory
Cambridge MA 02139