> Date:          Sat, 06 Mar 2004 12:05:45 +0900
> From:          Yasuki Arasaki <[log in to unmask]>

> The one thing I don't like about Fortran is [...] 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.

In what way?
Default real is default real.
1. 2. 3. 4. 5. etc are default reals.
They are always default real.
They never change from default real.

> The situation can be fixed (in decades time) by enabling somehow
> the configuration of default real type.

If it works, don't fix it.

> 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 precision obviously depends on the hardware being used.

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

But some have 8-byte reals.

> 3. All current processors support 8-byte reals (details of
>   implementation vary from processor to processor).

If you mean single precision (default) reals, that's not true.

> 4. Some current processors support real kinds larger than 8 bytes.

But not all.

> 5. To ensure maximum portability of a program, a named kind type
>   parameter is supplied to all REAL specifications and literals.

All programs that use default real are portable, by definition.
All programs that use (double precision) real are portable.
This is required by the standard.
Appropriate statements to obtain these precisions are:
real :: x
real (kind=kind(1.0d0)) :: y
and
double precision :: y
etc.

If you are using   real*4 x    or somesuch, then that is not portable.

> Some
>   conversion intrinsics (REAL, CMPLX) also require specification of
>   kind type parameter.

CMPLX is somewhat of an oddball, as it is not generic, and requires
that the kind be specified for a non-default result.

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

Default real is whatever the processor provides, and it doesn't
have to be 4 bytes.
I perceive a long-term trend to a longer size for default real.

> 7. Consequently, double precision real is converging on 8 bytes.

See 6.

> 8. Most (if not all) current processors have options to change
>   precisions of real kinds from the processors' default.

Not all.

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

Programs can be written to use whatever precision the user wants,
and in a portable way.

Some vendors offered such a facility for F77 programs because
there was no simple way to change the type other than by
a pre-processor.  In later standards, it is simple to do this
using standard Fortran.

> Details of these options vary
>   considerably from processor to processor.

That's why it is better to write the program in such a way
that the desired precision can be obtained portably.

> 9. There are many applications typical of Fortran where 4-byte real
>   does not offer enough precision.

Then write the program so that it uses double or another 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.

It is not necessary to do so for all real literals.

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

Wouldn't you then have to specify the kind for single precision literals?
And all extended precision literals?

> 3. The means to make default real 8 bytes is available on most (if not
>   all) processors as compile options.

"Most" is not sufficient reason to make it the default.
For some compilers, the default is immutable.
Better to write the program so that it uses the desired precision,
and in a portable way.

> However, the detailed effect of
>   such options vary from processor to processor so that they cannot be
>   depended on for portable programs.

That's right, and that's why it is a good idea to write the Fortran
program in a portable way.

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

???

What you propose would not be portable -- a program that
uses double precision on one system under "compatability real"
would be obliged to run under single precision under another,
when double precision was desired.

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

A compiler option (which cannot be standard and thus cannot be portable)
cannot be a standard way.

> 3. Further into the future, the default default real might be changed
>   to some kind other than the compatiblity real kind.

Groan.  There's no consistency here.

> There will be
>   compiler options that change the default back to the compatiblity
>   kind.

Really?

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

Definitely not.  That's a potential source of error and incompatibility.

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

Could break legacy code.

> 6. The following proposed changes make special storage association
>   simply not work when the default real is changed.

Breaks legacy code.

> Changing size of
>   default real does not automatically change size of any other types
>   unlike some portability compiler options. Is that OK?
>
> Yasuki Arasaki
> [log in to unmask]