From: robin on
"Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message
news:ron-shepard-9C2315.13402911102009(a)forte.easynews.com...
| In article <pdgAm.46773$ze1.38057(a)news-server.bigpond.net.au>,
| "robin" <robin_v(a)bigpond.com> wrote:
|
| > "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message
| > news:haofna$of4$1(a)naig.caltech.edu...
| > | analyst41(a)hotmail.com wrote:
| > | (snip, someone wrote)
| > |
| > | <> > ?read (cscr,*,end=100,err=100)
| > | onvar,(var1(j),j=1,6),pulsevar,(var2(j),j=1,1000)
| > |
| > | (snip)
| > |
| > | < why is it so hard to retain the value of j when the first of the two
| > | < following events occurs
| > |
| > | < (1) The read list is satified (j = number items asked for plus 1)
| > |
| > | < (2) EOR, EOF, ERR occurs (j = number of items read
| > | upto that time plus 1)
| > |
| > | It isn't that it is so hard, but that the standard doesn't requite it.
| > |
| > | It often happens deep in the I/O library.
| >
| > The control variable, namely, "I" is in the program, not in the library.
| > That's the value that's updated on each iteration of the loop.
|
| The above read statement is equivalent to
|
| read (cscr,*,end=100,err=100)onvar,var1(1:6),pulsevar,var2(1:1000)

But it isn't equivalent because there is no explicit loop control variable.

| where there is no loop index that is updated because there is no
| loop.

There is a loop somewhere. That's what 1:6 implies,
and what 1:1000 implies.

| That is the essential difference in an "implied" and an
| "explicit" loop.

An "implied DO" is actually an explicit loop, viz, (x(i), I=1,N))

Do you see it now? It's the capitalised part, in the outer parentheses.

| I have used compilers in the past that attempted
| to treat the two read statements differently (using full arrays in
| f77, not with f90 slices), and there is a very large difference in
| the efficiency in the two cases. In one approach, there is a
| library i/o call for each item within the implied do loops, in the
| other approach there is a single library call for the entire array,
| obviously a large difference in overhead for the two approaches.
|
| If the standard had required the information to be available, then
| it would be possible to return that value from the i/o library to
| the calling program

Whereever it is, it's available trivially.


From: Arno on
> Well, yes, you could.... except that checking for letters isn't
> particularly useful thing to do for the OP's problem. The problem
> involves blank-delimitted fields. Nothing in it specified letters to
> have any particular role. Checking for blanks and non-blanks is much
> more relevant. One could also do that with IACHAR, but scan, index, and
> verify are a little higher level.

Yes, but there was a field called 'pulse' in the example and this
field could be anything in the actual data file. So, I understood that
checking for non-numbers was actually relevant. Maybe I just
misunderstood; it is not really important.

Arno
From: Arno on
> While there is some use for IACHAR, you wouldn't use it
> to check for letters.  You would check by using character stings.

Oh, actually I am using it to check letters. Is there a better/more
elegant way? I would be happy to learn about it.

Arno

From: dpb on
Arno wrote:
>> While there is some use for IACHAR, you wouldn't use it
>> to check for letters. You would check by using character stings.
>
> Oh, actually I am using it to check letters. Is there a better/more
> elegant way? I would be happy to learn about it.

Depends on what you're actually doing.

INDEX, VERIFY, SCAN all have uses depending, again...

Whether more have been added w/ later Standards as well I've not looked
at, either.

--
From: Richard Maine on
Arno <arnoinperu(a)hotmail.com> wrote:

> > Well, yes, you could.... except that checking for letters isn't
> > particularly useful thing to do for the OP's problem. The problem
> > involves blank-delimitted fields. Nothing in it specified letters to
> > have any particular role. Checking for blanks and non-blanks is much
> > more relevant. One could also do that with IACHAR, but scan, index, and
> > verify are a little higher level.
>
> Yes, but there was a field called 'pulse' in the example and this
> field could be anything in the actual data file. So, I understood that
> checking for non-numbers was actually relevant. Maybe I just
> misunderstood; it is not really important.

Letters can also appear in numeric data. (Consider 1.2d3) And if the
field "pulse" can be "anything", then anything includes things that
aren't necessarily letters. "Anything" is the opposite of a precise
definition.

While I agree that it isn't highly relevant to the question at hand, as
solutions have been shown, I think it highly relevant to this general
class of problem to realize that one requires a precise statement of
exactly what defines the requirements. I would say that most of the work
in many such problems is in the precise definition of the problem.
That's even most of the work in many programming problems.

I do think it useful to point that out. One might think it too obvious
to be worth mentioning... at least if one hadn't seen the many, many
questions allegedy about Fortran, which turn out to really be more
questions about how to precisely formulate some problem.

Things like this has come up on occasion in drafting the Fortran
standard as well. I've seen people try to define something in the
standard by giving examples. Examples almost never constitute a precise
definition.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain