From: robin on 12 Oct 2009 10:28 "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 12 Oct 2009 12:00 > 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 12 Oct 2009 12:00 > 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 12 Oct 2009 12:20 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 12 Oct 2009 12:32
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 |