string stuff
in [Fortran]
|
From: analyst41 on 11 Oct 2009 19:58 On Oct 11, 4:49 pm, dpb <n...(a)non.net> wrote: > analys...(a)hotmail.com wrote: > > ... > > > That sounds interesting: We know that "true" EORs can only occur > > after the last columnn in the database. So if one sees them "in > > between" one can throw them out. > > ... > > One last thought that might help the parsing...is there the possibility > of exporting as tab-delimited instead of csv? _IF_ (the proverbial "big > if" :) ) could and there's not a tab in the text fields, could make the > field identification simpler... > > -- Thanks a lot. To SQL client experts = can one download tables as tab delimited files? Thanks.
From: analyst41 on 11 Oct 2009 20:20 On Oct 11, 2:40 pm, Ron Shepard <ron-shep...(a)NOSPAM.comcast.net> wrote: > In article <pdgAm.46773$ze1.38...(a)news-server.bigpond.net.au>, > > > > > > "robin" <robi...(a)bigpond.com> wrote: > > "glen herrmannsfeldt" <g...(a)ugcs.caltech.edu> wrote in message > >news:haofna$of4$1(a)naig.caltech.edu... > > | 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. > > > 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) > > where there is no loop index that is updated because there is no > loop. That is the essential difference in an "implied" and an > "explicit" loop. 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 (or, given that the i/o library probably works > in terms of memory addresses and strides, at least enough > information could be returned for the calling program to determine > the effective loop value) but that is not the situation, the > language does not require it to be returned and it prohibits the > programmer from attempting to use the value. In some cases > involving implied do loops (e.g. in data statements, I forget now if > i/o lists are included), the loop variables are actually a different > entity from other integers that have the same name -- effectively, > in the same scoping unit there are different "integers" that all > share the same name. > > $.02 -Ron Shepard- Hide quoted text - > > - Show quoted text - This nitpicking misses the point. the command "get me up to N things (bytes or items) and tell me how many (bytes or items) you got" is probably STILL absent from official fortran - a lack that in my opinion is the greatest reason for Fortran's underrepresentation in software projects in which its other strengths would have made it the natural choice.
From: glen herrmannsfeldt on 11 Oct 2009 21:59 analyst41(a)hotmail.com wrote: (snip) > This nitpicking misses the point. the command "get me up to N things > (bytes or items) and tell me how many (bytes or items) you got" is > probably STILL absent from official fortran - a lack that in my > opinion is the greatest reason for Fortran's underrepresentation in > software projects in which its other strengths would have made it the > natural choice. I believe that with non-advancing I/O it can be done. That is probably easiest with list-directed input, and I don't see any rule against combining them. It is likely less efficient than it otherwise might be, but that doesn't seem to slow down users of other languages with similar features. If you use the r* (repeat factor) form for list-directed input it might fail if used in a loop reading one item at a time. -- glen
From: robin on 12 Oct 2009 10:28 <analyst41(a)hotmail.com> wrote in message news:d073b875-d01e-4267-86dc-034921586d97(a)z24g2000yqb.googlegroups.com... >Is there a Windows/DOS tool that will let me see the EOR characters? Fileit!
From: robin on 12 Oct 2009 10:28
"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:has4ln$rvr$1(a)naig.caltech.edu... | 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. The designer of the library is also the designer of the compiler. It's trivial to update the variable, and there's no reason that it can't be updated to provide the current value of the variable. Since the standard didn't require that the value be updated, then the designer didn't go out of his way to do it. |