Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!uunet!deimos.cis.ksu.edu!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 (MORE)
Message-ID: <50500168@uxe.cso.uiuc.edu>
Date: 15 Nov 89 10:30:58 GMT
References: <7662@xenna.Xylogics.COM>
Lines: 109
Nf-ID: #R:xenna.Xylogics.COM:7662:uxe.cso.uiuc.edu:50500168:000:5221
Nf-From: uxe.cso.uiuc.edu!hirchert    Nov 14 13:47:00 1989


Pete Matthews (uucp@xylogics.UUCP) writes:
>                    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.

15% sounds about right for the instruction speed penalty, but what about the
effects of the increased storage?  This can include problems with the cache
or virtual memory working set, as well as I/O bandwidth issues.  (Actually,
I'm sympathetic to the idea that most numerical work is done in more than 32
bits and that in most cases the performance penalty is minor, but we should
recognize that this isn't always true.)

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

I see at least two potential problems with this approach:

1. Some machines have more than one precision beyond DOUBLE PRECISION.  This
   provides no standard way to support all of them.

2. Some people depend on REAL being the same size as INTEGER and DOUBLE
   PRECISION being twice the size of REAL in order to do their own storage
   management.  You scheme would break that assumption on some machines.
   The switch you suggest might "fix" things, but at the cost of confusion
   about which switch settings are necessary to make a program work.

The necessity of being compatible with FORTRAN 77 is so overwhelming that the
people on X3J3 who favored this approach found it necessary to leave REAL and
DOUBLE PRECISION alone and instead proposed two new data types that were
associated with specific minimum precisions.  (X3's recent change in X3J3's
program of work appears to require compatibility with FORTRAN 77, so your
proposal may not be an alternative open to X3J3.)

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

[Another approach might be to provide a means of specifying what properties
are expected of the (default) REAL type.  In the absence of such a
specification, this could default to being the same size as INTEGER, but
in the presence of such a specification, both constants and variables could
be modified to your requirements with a single statement.]

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

To me, you are just creating a different syntax for the interface block.
Among the disadvantages of a syntax based on extending the EXTERNAL statement
are the following:

1. You are using a different syntax to represent this information at the
   reference than was used at the definition.  Thus the user is forced to
   reenter it.  The interface block proposed by X3J3 uses the same syntax,
   so the statements that define the interface can just be copied into the
   interface block (or placed in an INCLUDE files for use in both places).

2. In a procedure with a large number of arguments, you may have trouble with
   the continuation limit.

3. This approach does not appear to deal well with the problem of specifying
   multiple attributes for an argument or function result (e.g., an array-
   valued function result).

4. This approach may have problems expressing function results whose attributes
   a related to attributes or values of its arguments (e.g., a CHARACTER
   function whose output length depends on the length and/or value of an
   input argument.)

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

1. There are problems with this in RECURSIVE functions and subroutines.

2. It is equally true of the syntax proposed by X3J3.

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

You just are choosing different parts of the existing structure to extend.
In many cases, when you try to work out the details, these approaches aren't
as simple as they first seem.  When X3J3 has added a feature in a way other
than the "obvious" way, it usually means the X3J3 found serious problems in
doing things in the "obvious" way.

>Pete Matthews
>Draper Laboratory
>Cambridge MA 02139

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