string stuff
in [Fortran]
|
From: Richard Maine on 9 Oct 2009 11:20 Arno <arnoinperu(a)hotmail.com> wrote: > checking for letters can be done with IACHAR 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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 9 Oct 2009 11:26 GaryScott <garylscott(a)sbcglobal.net> wrote: > On Oct 7, 10:26 am, Bart Vandewoestyne > <MyFirstName.MyLastN...(a)telenet.be> wrote: > > On 2009-10-07, dpb <n...(a)non.net> wrote: > > > > >> Any suggestions on how to do this? > > > > > idx = index(ps_string, 'pulse', back=.true.) + len('pulse')+1 > > > left_str = ps_string(1:idx-1) > > > rite_str = ps_string(idx:len_trim(ps_string) > > > > Sorry... i forgot to mention that the text 'pulse' can also be > > something else and with a different length... so the above trick > > doesn't work for me. > > > I didn't quite understand why you could not simply add a second > > if (idx .eq. 0) then > idx = index(ps_string, 'somehthingelse', back=.true.) +len > ('somethingelse')+1 > ... > i.e. if you don't find a 'pulse' then keep checking for the alternate > key words... You are making the assumption that there is a relatively short list of specific allowed keywords (and with specific letter case or one needs to preprocess the string to monocase it). I don't know whether or not that is so. Might be, but it wasn't stated explicitly. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: GaryScott on 9 Oct 2009 12:00 On Oct 9, 10:26 am, nos...(a)see.signature (Richard Maine) wrote: > GaryScott <garylsc...(a)sbcglobal.net> wrote: > > On Oct 7, 10:26 am, Bart Vandewoestyne > > <MyFirstName.MyLastN...(a)telenet.be> wrote: > > > On 2009-10-07, dpb <n...(a)non.net> wrote: > > > > >> Any suggestions on how to do this? > > > > > idx = index(ps_string, 'pulse', back=.true.) + len('pulse')+1 > > > > left_str = ps_string(1:idx-1) > > > > rite_str = ps_string(idx:len_trim(ps_string) > > > > Sorry... i forgot to mention that the text 'pulse' can also be > > > something else and with a different length... so the above trick > > > doesn't work for me. > > > I didn't quite understand why you could not simply add a second > > > if (idx .eq. 0) then > > idx = index(ps_string, 'somehthingelse', back=.true.) +len > > ('somethingelse')+1 > > ... > > i.e. if you don't find a 'pulse' then keep checking for the alternate > > key words... > > You are making the assumption that there is a relatively short list of > specific allowed keywords (and with specific letter case or one needs to > preprocess the string to monocase it). I don't know whether or not that > is so. Might be, but it wasn't stated explicitly. > Of course, I'm trying to tease out a bit of additional information... (maybe not the most efficient approach, but it keeps it interesting for me) > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain- Hide quoted text - > > - Show quoted text -
From: Richard Maine on 9 Oct 2009 12:26 GaryScott <garylscott(a)sbcglobal.net> wrote: > On Oct 9, 10:26 am, nos...(a)see.signature (Richard Maine) wrote: > > You are making the assumption that.... > > I don't know whether or not that > > is so. Might be, but it wasn't stated explicitly. > > > Of course, I'm trying to tease out a bit of additional information... > (maybe not the most efficient approach, but it keeps it interesting > for me) Ak. Ok. I've been in the position of trying to tease out information in the newsgroup often enough. I tend to find it more frustrating than interesting, though that's probably because it is so often really basic information that I'm trying to tease out and the difficulty of getting the basics gives me a vision of a long and painful trek to get anywhere useful. There are the people who ask vague questions without showing any code at all, then after repeated requests for the code, show a single line of code that probably isn't where the problem is, then after more repeated requests, show a few more lines that still don't include the requested declarations or other context, etc. I tend to give up on those after a while. The additional information here relates to a finer detail, admitedly a detail needed for the kind of precise problem specification that I'd insist on if I were actually needing to program the app in question. I like to minimize unstated assumptions; all too often they turn out to be wrong. For example, don't assume that people never write numbers with embedded blanks or commas. If that's to be part of the specifications, it needs to be said rather than just assumed. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: analyst41 on 9 Oct 2009 18:50
On Oct 9, 10:59 am, "robin" <robi...(a)bigpond.com> wrote: > <analys...(a)hotmail.com> wrote in messagenews:c3b4a774-5a3e-4b22-9df5-9434c8b74577(a)s6g2000vbp.googlegroups.com... > >How about this? > > character cscr*100,onvar*2,pulsevar*5 > > dimension var1(6),var2(1000) > > cscr = 'on 0.2 0.2 0.02 0.02 0.01 0.01 pulse 5.0e8 100e3' > > var2=-1 > > read (cscr,*,end=100,err=100) onvar,(var1(j),j=1,6),pulsevar,(var2(j),j=1,1000) > > > 100 continue > > print *,trim(onvar),var1,trim(pulsevar),var2(1:5) > > stop > > end > >output: > >on 0.200000003 0.200000003 1.99999996E-02 1.99999996E-02 > >9.99999978E-03 9.999999 > >78E-03 pulse 500000000. 100000.000 -1.00000000 -1.00000000 -1.00000000 > >Program Completed > >Press Enter to Continue. > >initialize var2 to soemthing that will not occr in the input. > >This is a bit dumb, but I don't know how to capture the value of j > >when EOF,ERR or EOR occurs in the second implied do-loop. But the > >first occrrence of -1 will tell you when input data stops. > > The value of j is undefined when termination of the READ occurs.- Hide quoted text - > > - Show quoted text - 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) Lahey fortran coplies with (1) but gives j = 0 when the read list cannot be satisfied. |