string stuff
in [Fortran]
|
From: robin on 11 Oct 2009 03:57 "Arno" <arnoinperu(a)hotmail.com> wrote in message news:f1e9a844-34b8-4f9f-b47b-8619809b9097(a)l13g2000yqb.googlegroups.com... >> You can read the entire line as you suggested. >> If all lines commence with the word "on", you can effectively ignore it, >> beginning aby search from position 3.. >> If lines commence with other words, you can search for the first blank. >> Then search for a letter. That will take you to the second word. >checking for letters can be done with IACHAR While there is some use for IACHAR, you wouldn't use it to check for letters. You would check by using character stings.
From: robin on 11 Oct 2009 03:57 <analyst41(a)hotmail.com> wrote in message news:514159c6-a861-4e53-8b35-4d60bec2b898(a)v36g2000yqv.googlegroups.com... >On Oct 9, 7:07 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: >> analys...(a)hotmail.com 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. >>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. Indeed!! In point of fact, the designers of PL/I (1964) saw the need, and included a special function for just this very situation. The function COUNT returns the number of values transmitted in the previous I/O operation. Since the designers of PL/I included FORTRAN users, you can be sure that it was something that was seen as important even then and was something seen as lacking in Fortran. [PL/I also has the equivalent of an implied DO, and the value of the control variable is available.]
From: glen herrmannsfeldt on 11 Oct 2009 04:23 robin <robin_v(a)bigpond.com> wrote: (snip on implied DO) > 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. That is an implementation detail. I remember when the OS/360 Fortran compilers switched from having a loop in the program to a loop in the I/O library. It was significant as it required that newly compiled programs be linked with the new library. The library, as usual, was backward compatible with older programs. If IBM could do it in 1973 I would expect that many others since could do it, but it is really a decision that the library designer has to make, not you. -- glen
From: analyst41 on 11 Oct 2009 08:28 On Oct 11, 4:23 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > robin <robi...(a)bigpond.com> wrote: > > (snip on implied DO) > > > 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. > > That is an implementation detail. > > I remember when the OS/360 Fortran compilers switched from having > a loop in the program to a loop in the I/O library. It was significant > as it required that newly compiled programs be linked with the new > library. The library, as usual, was backward compatible with older > programs. > > If IBM could do it in 1973 I would expect that many others > since could do it, but it is really a decision that the library > designer has to make, not you. > > -- glen I am asking this question for a practical reason. I extract a csv file from a database and apparently their native character encoding isn't 7-bit ASCII. When I read this extracted file with fortran two thing shappen (1) (trivial) some characters are misinterpreted - even excel, notepad etc, do the same thing. (2) (non-trivial) spurious "End of record" markers are seen by Fortran, Excel etc. (If I eliminate the character fields from the database extract, this doesn't happen) and the file as read in sees more records than there are rows in the database. (3) I posed this problem earlier to the ng. and although I received some suggestions, I still haven't solved the problem.
From: dpb on 11 Oct 2009 09:20
analyst41(a)hotmail.com wrote: .... > I am asking this question for a practical reason. I extract a csv > file from a database and apparently their native character encoding > isn't 7-bit ASCII. When I read this extracted file with fortran two > thing shappen > > (1) (trivial) some characters are misinterpreted - even excel, notepad > etc, do the same thing. > > (2) (non-trivial) spurious "End of record" markers are seen by > Fortran, Excel etc. (If I eliminate the character fields from the > database extract, this doesn't happen) and the file as read in sees > more records than there are rows in the database. > > (3) I posed this problem earlier to the ng. and although I received > some suggestions, I still haven't solved the problem. This doesn't seem to be a Fortran problem, really, but one in the file generation from the database. What hardware, OS, database, etc., ... might lead to somebody having input to resolving the problem. -- |