The one thing I don't like about Fortran is not the "%" (I don't
often use derived types anyway) but the fact that default real seems
to be converging on four bytes. In F77 days I used only
DOUBLE PRECISION with all real literals with a D exponent. That was
ugly then, but in F90 I explicitly specify kind parameters for all
real literals (not really all, I use "2" instead of "2.0_rk").
Fortran is supposed to be for number crunching, but the most
convenient default real can not be trusted.
The situation can be fixed (in decades time) by enabling somehow
the configuration of default real type. Google shows that this
point has been brought up several times before, but was not persued
further because it was just too much bother.
I think the simplest way to do it is to separate default real type
from the special storage association rules it has with the other
default types, and then enable specification of the default real
kind parameter value (from outside the program) by processor
dependent means. Default integer and logical (and much less
default character) are not touched. I just don't see much use in
configurable default integer types.
I'd like to hear other people's thoughts on this before I write
this up into a proposal. So here's the idea (sorry it's kind of
longish):
-----
Summary of current state:
1. Fortran standard does not specify precision of real kinds. The
standard does specify that double precision real must have more
precision than default real and that double precision real occupy
twice the storage unit of default real. Default real/integer/logical
occupy the same storage unit.
2. Most (if not all) current processors support 4-byte reals (details
of implementation vary from processor to processor).
3. All current processors support 8-byte reals (details of
implementation vary from processor to processor).
4. Some current processors support real kinds larger than 8 bytes.
5. To ensure maximum portability of a program, a named kind type
parameter is supplied to all REAL specifications and literals. Some
conversion intrinsics (REAL, CMPLX) also require specification of
kind type parameter.
6. Default real is converging on 4 bytes, i.e. many processors choose
4 bytes as default real and there is pressure for other processors to
adopt that default size due to portability reasons.
7. Consequently, double precision real is converging on 8 bytes.
8. Most (if not all) current processors have options to change
precisions of real kinds from the processors' default. They may be
offered as portability aids (for porting programs written for
processors with different precisions for default real), or they may
be offered as coding aids (for auto-converting programs written for
one precision to another precision). Details of these options vary
considerably from processor to processor.
9. There are many applications typical of Fortran where 4-byte real
does not offer enough precision.
10. Popular languages other than Fortran have chosen 8-byte reals for
their "default".
What I think:
1. Having to specify kind type parameters for all real literals
unnecessarily clutters programs.
2. If the default real could be assumed to have at least 8 bytes,
there won't be a need to specify kind type parameters for all real
literals (for most problems, the default would simply be enough).
3. The means to make default real 8 bytes is available on most (if not
all) processors as compile options. However, the detailed effect of
such options vary from processor to processor so that they cannot be
depended on for portable programs.
What I propose to do to the standard:
1. Introduce a "compatibility" real kind that must be supported by all
processors. The compatibility real kind assumes all the special
storage association rules given currently to the default real kind.
2. The default real kind is stripped of any special status other than
being the default. Instead, default real kind is chosen to be either
compatiblity real or some other real kind by processor defined means.
3. One way of how changing the default real kind affects rest of the
language is worked out, so that this feature can be portably used.
How this affects existing and future processors.
1. Existing processors need no modification to comply to this revision
(other than in accompanying documentation). The processor can simply
be said to always chose the compatibility real kind for default.
2. A future processor might offer compiler options that implement
this "standard" way of specifying precision for default real, along
with other options that the processor already has.
3. Further into the future, the default default real might be changed
to some kind other than the compatiblity real kind. There will be
compiler options that change the default back to the compatiblity
kind.
Things that must be decided:
1. A name for the "compatibility" real kind. Throughout this text I
use the term compatibility real kind to refer to a real kind with
special storage association properties currently given to default
real. A better name is probably needed.
2. Should specific names of intrinsic functions be for (configurable)
default real or compatibility real? I think the latter is better as
specific names are mostly used in compatibility with older code.
3. Should different program units be allowed to have different kinds
for default real? Yes. We need to link legacy code with new code.
4. What to do with default integer or default logical? I say there is
no need to change them.
5. And what to do with default character? I say don't change.
6. The following proposed changes make special storage association
simply not work when the default real is changed. Changing size of
default real does not automatically change size of any other types
unlike some portability compiler options. Is that OK?
Where to change:
1. In section "4.4.2 Real type", F2003 says
> If the type keyword REAL is specified and the kind type parameter
> is not specified, the default kind value is KIND (0.0) and the type
> specified is default real.
Prior to this, the existence of "compatibility" real kind must be
stated, and then following this statement, "the default real kind is
either the compatibility real kind or some other real kind specified
by processor defined means" could be added.
2. In the same section,
> The decimal precision of the double precision real approximation
> method shall be greater than that of the default real method.
is changed to refer to compatibility real instead of default real.
3. Wording in section "4.4.3 Complex type" does not change but
introduction of the term compatibility complex type might be added.
4. The following state special storage association rules for default
real and default complex. These should be changed to refer to
compatibility kinds.
a) constraints C580 and C583, and NOTE 5.37 (EQUIVALENCE rules)
b) 5.5.2.3 Common association
c) 12.5.2.4 ENTRY statement
5. "13.6 Specific names for standard intrinsic functions" lists the
argument types for intrinsic functions' specific names. Default real
and default complex here should be changed to refer to compatibility
kinds.
6. "13.7.33 DPROD(X,Y)" states DPROD works on default real types.
This should be changed to refer to compatibility types.
7. (1) and (2) of "16.4.3.1 Storage sequence" assigns numeric storage
units to default real and default complex. These should be changed to
refer to compatibility kinds.
8. (2) in "16.4.3.3 Association of scalar data objects" state special
partial association rules for default real and default complex.
These should refer to compatibility kinds instead.
9. (13) and (14) of "16.5.5 Events that cause variables to become
defined", and (1) of "16.5.6 Events that cause variables to become
undefined" state special partial association rules between default
real and default complex kind. These should refer to compatiblity
kinds.
10. "numeric storage unit" and "unspecified storage unit" in the
glossary refers to default real which should be changed to refer to
compatibility kind.
11. If different program units can have different kinds specified for
the default real, that fact might be stated somewhere.
Where not to change:
1. In "4.4.3 Complex type", a complex literal with both parts integer
is defined to be default complex type. This should be left as is
(rather than change it to compatibility complex).
2. In NOTE 5.1, there is an example of a default real declaration,
which should not be changed to refer to compatibility real.
3. In "5.3 IMPLICIT statement", the default mapping of (A-H,O-Z) to
default real is stated. This should not refer to compatibility real.
4. NOTE 7.11 refers to a default real X as an example. This need not
be changed.
5. "13.7.20 CMPLX(X[,Y,KIND])" specifies that omitting KIND results
in default complex. This should not be changed (CMPLX(X,Y) results
the "current" default complex).
6. The example in "13.7.59 KIND(X)" refers to default real.
This should not be changed.
7. "13.7.97 REAL(A[,KIND])" specifies that omitting KIND results in
default real. This should not be changed.
8. The example in "13.7.106 SELECTED_REAL_KIND([P,R])" refers to a
default real approximation. This need not be changed.
9. "14.10 Specifications of the procedures" assumes IEEE arithmetic
for default real in the examples. This need not be changed. Specific
references to default real appear in 14.10.17, 14.10.23, and
14.10.34. These also need no change.
Clarification:
1. What this attempts to do is to allow specifying (outside the
program) a kind value for default real. It can be specified to be
the compatibility kind (this is the only option on all existing
processors) or some other kind. This "option" does not attempt to
change the associated representations for individual kind values. It
also does not attempt to change kind values for anything other than
default real (no automatic promotion of default integer or double
precision real).
2. Features left in for compatibility (such as DOUBLE PRECISION,
DPROD, specific names for intrinsic functions, storage association)
work only with compatibility kinds. Their use is not extended to the
configurable default kind.
3. Defaults for conversion functions REAL and CMPLX, and the automatic
conversion of integer complex literals are to the "default" kind not
the compatibility kind.
4. The processor is not required to make available all supported real
kinds for default real. A processor may choose to support only the
compatibility real kind for default.
5. Changing the default real breaks only "special" storage
association, i.e., that between different default types. "Good"
practices like all COMMON blocks having the same mapping are not
affected. What it breaks is storage association between different
default types, and partial association between default real and
default complex.
6. For linking new code with old, the old code using special storage
association rules can be compiled with default real set to the
compatibility kind, and the new code compiled with some other
default real. The new code will use explicit kind type parameters
specifying compatibility kind to access the old code.
-----
and that's it. Thanks
--
Yasuki Arasaki
[log in to unmask]
|