string stuff
in [Fortran]
|
From: glen herrmannsfeldt on 9 Oct 2009 19:07 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. If the standard required it, I am sure library writers would find a way to get it out. C doesn't have implied loops in I/O, so if one wants to do this an explicit loop is usually used. In the case of partially satisfying an input operation, C does guarantee that the remaining items are not modified. For example: scanf("%d:%d:%d",&i,&j,&k); The is, three integers separated by colons, if only one or two are input (terminating on a non-numeric character, for example) or a colon is missing j and/or k will keep its previous value. -- glen
From: analyst41 on 9 Oct 2009 21:47 On Oct 9, 7:07 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > analys...(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. If the standard required > it, I am sure library writers would find a way to get it out. > > C doesn't have implied loops in I/O, so if one wants to do > this an explicit loop is usually used. In the case of partially > satisfying an input operation, C does guarantee that the remaining > items are not modified. For example: > > scanf("%d:%d:%d",&i,&j,&k); > > The is, three integers separated by colons, if only one or two > are input (terminating on a non-numeric character, for example) > or a colon is missing j and/or k will keep its previous value. > > -- glen Getting on my soapbox a little, this is an example illustrating why Fortran is becoming obsolescent - the language designers seem to beblithely uninterested in getting "messy" data (relational tables,csv data with headers, sockets, rich media etc.) into a Fortran program. They are still stuck in the 1960s "flat files in" and "flat files out" (on the same processor) as the I/O paradigm. If records in a data source contain variable number of delimted items, the unsefulness of preserving the implied-do variable when items run out is obvious - but apparently not to the language deisgners.
From: glen herrmannsfeldt on 9 Oct 2009 23:06 analyst41(a)hotmail.com wrote: > Getting on my soapbox a little, this is an example illustrating why > Fortran is becoming obsolescent - the language designers seem to > beblithely uninterested in getting "messy" data (relational tables,csv > data with headers, sockets, rich media etc.) into a Fortran program. > They are still stuck in the 1960s "flat files in" and "flat files > out" (on the same processor) as the I/O paradigm. Well, there is now non-advancing I/O, more like the stream I/O of C and PL/I than the traditional Fortran record oriented form. If you read one item at a time with non-advancing I/O then I think you can get the count right. > If records in a data source contain variable number of delimted items, > the unsefulness of preserving the implied-do variable when items run > out is obvious - but apparently not to the language deisgners. It does get complicated in the case of implied DO. For example: read(*,*) (x(i),y(i),i=1,1000000) If there are an odd numbe of items, what about the last one? If you have more than one? read(*,*) (x(i),i=1,1000000),(y(i),i=1,1000000) -- glen
From: analyst41 on 10 Oct 2009 06:32 On Oct 9, 11:06 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > analys...(a)hotmail.com wrote: > > Getting on my soapbox a little, this is an example illustrating why > > Fortran is becoming obsolescent - the language designers seem to > > beblithely uninterested in getting "messy" data (relational tables,csv > > data with headers, sockets, rich media etc.) into a Fortran program. > > They are still stuck in the 1960s "flat files in" and "flat files > > out" (on the same processor) as the I/O paradigm. > > Well, there is now non-advancing I/O, more like the stream I/O > of C and PL/I than the traditional Fortran record oriented form. > > If you read one item at a time with non-advancing I/O then I > think you can get the count right. > > > If records in a data source contain variable number of delimted items, > > the unsefulness of preserving the implied-do variable when items run > > out is obvious - but apparently not to the language deisgners. > > It does get complicated in the case of implied DO. For example: > > read(*,*) (x(i),y(i),i=1,1000000) > > If there are an odd numbe of items, what about the last one? > > If you have more than one? > > read(*,*) (x(i),i=1,1000000),(y(i),i=1,1000000) > > -- glen I would read the incming items into a single array-buffer and if the compiler gives me the number of items read, then parcel the items in the buffer into the arrays where they are supposed to live using code. I have never used non-advancing I/O - would you check for EOR with that instead of EOF? I feel that there ought to be way of solving this problem without extracting delimiters "by hand".
From: robin on 11 Oct 2009 03:57
"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. |