On Jan 18, 2005, at 7:44 AM, Ian Chivers wrote:

> I have a query regarding real literal constants
> when reading data from a file or the terminal.

Woah... Slow down. Wrong direction. Without yet seeing which exact
question you are going to ask, I already see what I presume will be
much of the problem...

Literal constants do not appear in data files (including the terminal).
The term "literal constant" refers to something in Fortran source code,
*NOT* in data files. There are forms in data files that look similar to
some literal constants, but they are not literal constants and they
don't have exactly the same form.

This was messed up in the original f90 document, which inappropriately
used the term "constant". That was largely corrected in an f90
interpretation (though I think I recall finding one or two cases that
either got missed by that interp or slipped back in later).

> With the second read I do not need to add _long to the external data
> to get the higher precision. Is this standard conforming?

Ah. Ok. That one. There are several questions that could have resulted
from the above-mentioned confusion. This is one of them.

I'll mostly skip over the question of whether it is standard conforming
for compilers to provide more precision than requested. I  will note
that the question of whether it is standard conforming for a compiler
to do something is not necessarily the same question as whether it is
standard conforming for a program to depend on it. For example, a
standard-conforming compiler can support language extensions, but a
standard conforming program can't use them.

But in this case, that whole issue is irrelevant because you are trying
to apply the wrong concept. The data in the file doesn't *HAVE* a
precision. It is just a bunch of characters. The process of doing a
formatted read converts the characters into internal forms. It is the
internal forms that have kinds - not the characters.  (Well, the
characters have character kinds - usually default - but that's a
different matter). Note, for example, that if you have the characters
1234 in an input file, that doesn't necessarily represent an integer at
all. It could be read into a character variable as just a string of
characters. Or it could be 4 separate integers read with a 4I1 edit
descriptor.

Along this line, note that kind numbers are not part of the syntax
allowed for formatted input (or produced by formatted output). Since
kind numbers are compiler-dependent, putting them in formatted data
files would be problematic. Formatted data files are not supposed to be
compiler-dependent (well, not in that way anyway). And using named
constants wouldn't help. Named constants do not have global scope, even
in the source code. The same name can represent different constants in
different scoping units. I suppose that one *COULD* make the
interpretation of formatted data files depend on the particular scoping
unit it was read from (being careful with the definitions when multiple
scoping units are involved, as with UDDTIOP), but that particular mire
is not one that Fortran got stuck in.

If you happen to want to write something like the characters 1234_long
in a data file, you are certainly free to do so.  But you'll have to
use something other than an integer edit descriptor at least for the
underscore when writing it. When reading it, the parsing and
interpretation will be up to you to define, because the syntax won't
mean anything special to the compiler i/o run-times.

--
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain