> Date:          Sun, 07 Mar 2004 08:55:09 +0900
> From:          Yasuki Arasaki <[log in to unmask]>

> On Sun, 7 Mar 2004 09:24:27 +1000, Robin <[log in to unmask]> wrote:
>
> > Appropriate statements to obtain these precisions are:
> > real :: x
> > real (kind=kind(1.0d0)) :: y
> > and
> > double precision :: y
> > etc.
>
> No, these are not appropriate statements to obtain desired
> precisions.
>
> This is the portable way.
>
> integer, parameter :: sp = selected_real_kind(6,30)
> integer, parameter :: dp = selected_real_kind(12,60)
> real(sp) :: x
> real(dp) :: y
>
> ..and all real literals use _sp and _dp. There is nothing wrong
> with this approach except that it "clutters" programs with
> unnecessary (in my opinion) precision information all over the
> place.

What is wrong with this approach is that it makes it necessary
to give a kind to EVERY float constant.
        If you use default real, you do not need to give a kind
to default real constants.
That's why default real is there.  To make it simple to use.
You can also use the letter "e" as in 1.7E15, or "d" as in 1.7D-14
to specify a single or double precision constant, respectively.
        The default real is not only portable, it is guaranteed
to run with any Fortran.
        Likewise with double precision.
        And it is reliable, which is what you wanted.

> The default real is not used in this scheme because there
> is no way to specify a precision for it. It is what the
> processor happens to offer, which may or may not be what the
> user wants. And there is strong pressure to make the default the
> real type with the least precision,

There is no pressure to make the default the real type with the least
precision, because that is already the standard.

> because it has to have the
> same size as default integer, and the current popular size for
> it is 4 bytes.
>
> This is what I mean "default cannot be trusted".

Default real can be trusted.  It's fully portable.
The scheme you suggested is not fully portable
because it cannot be trusted.
There is no guarantee that it will always result in two distinct
precisions being obtained for a given computation.
This may be a problem if the precisions need to be different
in order to resolve a reference to a user-written generic function .

> > Wouldn't you then have to specify the kind for single precision literals?
> > And all extended precision literals?
>
> Yes. Configurable default real would chose one kind for default, and
> all other kinds would need explicit specification. At least you
> would be able to use default real for one kind.

You can use and depend on one now, namely, default real.

> Currently, it's
> zero kinds you can use without explicit specification (if you care
> about precisions).

Actually, it's one kind you can use without expllicit specification.
Which can be trusted, is reliable, and fully portable.

> > ???
> >
> > 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.
>
> This is the current situation

No, this is not the current system.
Under the current system, default real always gets single precision.
There is always guaranteed another greater precision available.

> (read "default" for "compatibility").
> It is seprate from the problem I'm trying to address. My proposal
> will not affect it (in any direct manner). I'm trying to introduce
> configurable default real without affecting existing programs.
> --
> Yasuki Arasaki
> [log in to unmask]