Prev: Suggession for your website
Next: scope of implied do-variable and initialize values
From: Benjamin on 31 May 2010 12:24
Hello all,

I have a quesion about reading one line with unknown number of data
points (eg. real numbers)

When I tried to read a headline containing the parameters for further
calculation,
I would like to know how to get the number of real numbers.
E.g.
100.2 101.3 101.5 100.7 193.3 ....

There is a line containing unknown number of real numbers, I would
like to use variable n to store this array.
BTW, I already defined a variable (comment) to store this string for
this line. I set integer max as 100
this is the part of my codes (the define part has been igored)

READ(comment, *, iostat = inObs) (n(i), i = 1, max)
IF inObs /= 0 then
...

But I don't know how to get the number of real numbers.
Sorry that my Fortran ability is poor, I hope anyone who is capable of
it, can give me some advices
From: robin on 1 Jun 2010 05:58
"Richard Maine" <nospam(a)see.signature> wrote in message news:1jjcs69.1d1qkq3om82auN%nospam(a)see.signature...

| What you can do, which is simillar in concept, but requires you to do
| more work, is parse out the data fields one at a time, keeping track of
| where you were.

This is exactly not what the OP wanted.
He wanted to know how many data items were there on the line.
Apparently, he wants to know that because the input data is
line oriented (see: subject line), which is a fairly common thing.

In other languages, this task is trival, and you would think
that after 55 years, it could be done easily in Fortran.

In PL/I, it's 3 lines including the input statement:

get edit (line) (L);
line = trim(line);
n = tally(line, ' ') - tally(line, ' ') + 1;


From: feenberg on 1 Jun 2010 09:29
On May 31, 12:24 pm, Benjamin <benjami...(a)googlemail.com> wrote:
> Hello all,
>
> I have a quesion about reading one line with unknown number of data
> points (eg. real numbers)
>
> When I tried to read a headline containing the parameters for further
> calculation,
> I would like to know how to get the number of real numbers.
> E.g.
> 100.2 101.3 101.5 100.7 193.3 ....
>
> There is a line containing unknown number of real numbers, I would
> like to use variable n to store this array.
> BTW, I already defined a variable (comment) to store this string for
> this line. I set integer max as 100
> this is the part of my codes (the define part has been igored)
>
> READ(comment, *, iostat = inObs) (n(i), i = 1, max)
> IF inObs /= 0 then
>    ...
>
> But I don't know how to get the number of real numbers.
> Sorry that my Fortran ability is poor, I hope anyone who is capable of
> it, can give me some advices

What about initializing n to some impossible values and then:

comment(last:last)='/'
write(99,*) comment
read(99,*) n(i),i=1,max

The / will terminate the free format read without an error, and then
you can count the number of valid n() values. The items not read from
unit 99 will retain their initialized values. I wouldn't trust i to
be
any particular value, though.

Daniel Feenberg
From: glen herrmannsfeldt on 1 Jun 2010 13:44
feenberg <feenberg(a)gmail.com> wrote:
(snip)

> What about initializing n to some impossible values and then:

> comment(last:last)='/'
> write(99,*) comment
> read(99,*) n(i),i=1,max

> The / will terminate the free format read without an error, and then
> you can count the number of valid n() values. The items not read from
> unit 99 will retain their initialized values. I wouldn't trust i to
> be any particular value, though.

Last I knew, the standard didn't require either i, nor n() to
have the appropriate values in the case of an incomplete read.
(I would put either END= or ERR= on, or it likely fail in other ways.)
(I think you also need parenthesis on the implied-DO.)

I might think, though, that it is time to change the standard
regarding this one. It isn't that hard to implement.
Note also that C's fscanf() does return the appropriate number
of values assigned, guarantees that values read are stored
correctly, and values not read are not changed.

The restrictions on this likely go back to the 704 index registers,
similar to the Fortran 66 restrictions on DO loops that were changed
in Fortran 77.

The last time I actually tried this was in the Fortran 77 days
on VAX/VMS, and I thought it was a bug. (Not having seen a copy
of an actual Fortran standard.) I even had the card to send to
DEC to report a bug, but didn't actually send it in.

-- glen
From: Richard Maine on 1 Jun 2010 16:42
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> feenberg <feenberg(a)gmail.com> wrote:
>
> > What about initializing n to some impossible values and then:
>
> > comment(last:last)='/'
> > write(99,*) comment
> > read(99,*) n(i),i=1,max
>
> > The / will terminate the free format read without an error, and then
> > you can count the number of valid n() values. The items not read from
> > unit 99 will retain their initialized values. I wouldn't trust i to
> > be any particular value, though.
>
> Last I knew, the standard didn't require either i, nor n() to
> have the appropriate values in the case of an incomplete read.
> (I would put either END= or ERR= on, or it likely fail in other ways.)

The standard doesn't talk about "incomplete reads" in such general
terms. What you say would be true for end of file or error conditions,
but it is not the case for a '/' terminator

A '/' terminator does leave appropriate values in n (I'd have to go read
more carefully to figure out the status of i). In particular, it "causes
termination of execution of that input statement after assignment of the
previous value." Note the "after assignment of the previous value" part.
Also, "If there are additional items in the input list, the effect is as
if null values had been supplied for them." Note that supplying null
values is not at all like hitting an end of file. It is more comparable
to the blank padding that applies to some explicit format reads.

I'm puzzled, by the way, as to why you would expect an end= to be useful
in this context, which involves a list-directed read with a '/'. The '/'
should stop the read before an end-of-file becomes relevant. I suppose
the '/' could possibly get "swallowed" by a prior unterminated character
string, but that's a bit arcane, particularly for numeric data; you'd
probably get an error for having the wrong data type first. It is true
that the code as shown (after adding the needed parens) would get an
end-of-file, but that is more appropriately addressed by fixing the
coding error (lack of a rewind) than by leaving the error in and adding
a handler for it.

I would also generally disagree with unqualified advice to add end= and
err=. I'm not quibbling about the distinction between those and iostat=
(which I usually prefer), but rather about the unqualified nature of the
suggestion. I would say that adding end= or err= (or iostat=) should be
done *ONLY* if you intend to do something useful after detecting those
conditions. The reason I am being picky about what might seem such an
obvious point is that I have seen people mislead by such unqualified
recommendations. They heard somewhere that they are supposed to put such
things on all I/O statements, so they do that. But lacking any plan of
subsequent action, they then ignore the detected conditions. That is
usually far worse than leaving the specifiers off and letting the system
take its default action, which will usually be an error message.

If you think you can generate a more useful error message than the
system is likely to, that's fine. It is sometimes the case in that you
might be able to provide better context. Or if you have alternatives
other than just an error message, that's even better. (In some
interactive cases, you can ask for a correction.) But don't just put in
an err= because someone suggested that you should do that, thinking that
just putting it in adequately followed the advice.

I do have a different criticism of feenberg's suggestion, though. I
think that the general notion of appending a '/' is a good one. But it
seems like an unnecessary complication to use a temporary file. That
adds all kinds of potential failure modes. Forgetting the rewind, as the
code shown does, is only one of many messier ones. Having added the '/'
to the "comment" variable, I'd just do an internal read from it.

Admitedly, list-directed reads from internal files have only been
standardized for 20 years now. But some compilers older than that
allowed it as an extension. :-)

> The restrictions on this likely go back to the 704 index registers,

I doubt it. I suspect it as having more to do with things like
buffering. I recall such things being discussed in committee. While I
don't recall all the details, I'm quite sure that the subject of 704
index registers never was mentioned.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 |  Next  |  Last
Pages: 1 2
Prev: Suggession for your website
Next: scope of implied do-variable and initialize values