My previous post is a bit long and dry. Please skip to the end
where there's a section "Clarification" that tries to summarize
what I wanted to say. Thanks.

On Fri, 5 Mar 2004 22:27:46 -0500, Peter Shenkin <[log in to unmask]>
wrote:

> What do you mean "cannot be trusted"?  Do you mean "cannot be
> trusted to be 8 bytes" or "cannot be trusted to be the same on
> all platforms"?

Cannot be trusted to have "the necessary precision". If you need
4 bytes real, then the current default real happens to be OK.
If you need 8 bytes real (or 16 or some other) then the current
default is not OK.

> The default size is generally the size that makes
> the most sense on the current hardware/OS.  On a 32-bit
> architecture, this is, well, 32 bits. Note that breaking
> the equivalence between default real and default integer
> sizes would wreak real havoc, and you really don't want
> 64-bit default ints in a 32-bit executable.

The default size for real is chosen to be the *integer* size
that makes the most sense. This is precisely because of what
you say. Shouldn't Fortran, being a number crunching language,
chose default size for real as the size that makes the most
sense as a real number on the current hardware/OS?
I'm trying to eliminate this requirement of real and integer
having the same size by introducing a special real kind that
is guaranteed to have the same size as default integer,
separately from the default real. If you need the equivalence,
you just specify the default to be this special kind (outside
of the program, i.e., no need to modify existing programs).
This "default real is the special kind" is intended to be the
default "default", by the way.

In case you don't need this equivalence, for example, when
you are dealing with fresh code created in Fortran 90, I'm
saying it would be nice to have a way to specify another
kind for default real.

> You seem to be assuming that all or most number-crunching
> applications require 8-byte reals.  I see no justification
> for that assumption.  Why not 16-byte reals, for that matter?

Well yes. I am assuming most number-crunching applications
require 8-byte reals. That's just my impression and I may be
mistaken here. But just substitute "many" for "most" and I
don't think it will affect the rest. Although my personal
ambition(?) is to get portable 8-byte default reals, the
content of the previous message was written without any
preference to 8-bytes. There is nothing in it that excludes
the use of 16-byte reals (or 4-byte or 10-byte reals) as
default real in there. (Actually, I'm saying there that the
only default choice required by the standard should be the
de facto 4-bytes real, or whatever currently in use as the
default real.)

> So my own view is that I don't see a problem with default
> reals generally being 4 bytes in length.  It seems to me
> that the mechanism we have for specifying other kinds is
> quite adequate, if that's what you need.

Well, I can understand that there would be many people
who won't need what I proposed. If you mostly work with
the current default real precision, there is no need to
change it.
--
Yasuki Arasaki
[log in to unmask]