On Mar 9, 2004, at 2:34 PM, [log in to unmask] wrote:
>
> 1. The standard also specifies scalar named constants for the four
> default
> kinds (and for double precision real) in ISO_FORTRAN_ENV,
> I don't like #1 because I don't like duplication.
I do like it because it is part of one of the possible ways to address
one
of my proposals - to simplify the most common requirements for kind
selection. That proposal is completely duplicative; it doesn't
provide noticeable new functionality, but rather asks for a simpler
syntax for capability we already have.
In the huge majority of existing codes, people don't start out by asking
for a precision of p and a range of r. Instead, they ask for 32-bit
or 64-bit reals and then have to translate their request into the
standard's terms. I find selected_real_kind(12,30) to be a pretty
verbose and nonintuitive spelling of 64-bit real. It is clear to
me that so do a lot of other people. But 64-bit reals are such a common
requirement that I think we should provide a simpler way to spell it,
even though that spelling will be pretty duplicative of
selected_real_kind(12,30). Yes, I know that they don't say exactly the
same thing in theory, but they are sure pretty close in practice.
As I noted in my proposal, f2003 does provide a slightly simpler way
to spell things like 64-bit integer. Using C interop, that can be
spelled
as C_INT64_T. Again, in theory that might be different from the obscure
spelling selected_int_kind(18), and the C_ prefix is slightly odd, but
it
isn't too bad. I find it odd that we provide a simpler way to specify
specific integer sizes than we do for reals; of course, the reason is
that
this only comes in through the back door of C interop. I want it in the
front entrance and I want to see both reals and integers covered.
That proposal got one of the most favorable votes at the J3 meeting.
Zero people hated it, zero disliked it, 6 liked it, and 4 loved it.
It also got quite favorable votes on complexity/difficulty, with
8 thinking it small, 2 thinking it medium, and nobody thinking it
large. My reading is that the proposal addressed a problem that
almost all of the committee has seen.
There are several possible ways of addressing the problem. I
specifically left that unspecified for now, wanting first to get
agreement that we should address it. But one of the ways is to
provide a few standard named constants for the kind parameters.
Since the whole point is simplicity, I don't think it will be well
achieved by having an array and "magic numbers" in the array
(I consider "1" to be a magic number if that's how you spell default).
> --
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|