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. 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, 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".
> 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. Currently, it's
zero kinds you can use without explicit specification (if you care
about precisions).
> ???
>
> 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 (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]
|