From: Richard Maine on
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
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
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
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
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.