On 8/9/2013 4:43 PM, Christian wrote:
...
> Just forget about the records I gave you and suppose a really simple case:
> Let the record be:
> 'ss45gg67tt'
>
> I want to have, after I textscanned it, the cell C so that:
> C(1)='ss' ;C(2)=[45]; C(3)='gg';C(4)=[67] and C(5)='tt'
>
> 45 and 67 should be read as floating number.
> The fortran equivalent would be (a2,f2,a2,f2,a2)
>
> Now suppose one field is missing and another is slightly different
> Let the record be:
> 'ss gg67 t'
>
> Then I want:
> C(1)='ss' ;C(2)=[]; C(3)='gg';C(4)=[67] and C(5)='t'
OK, that at least is understandable.
And, indeed, textscan() isn't smart enough (altho it is a little better
than fscanf() and friends). It _will_ parse the fixed fields if they're
all there and complete, but fails with the missing fields.
The test cases I had done I discover in going back only dealt with the
fixed width strings that can be separated (at least a _small_ step
forward) and I hadn't actually done the missing field on the expectation
of seeing an actual record to play with...
The really bizarre shortcoming is that even the ' t' subfield
fails--when C wants '%2s' it damn'd well just better be two characters
and even if 'delimiter','none' is in effect internally it still thinks a
leading blank is whitespace and ignores it so the conversion on the
field fails. It's truly hopeless.... :( How C ended up w/ such an
abomination is amazing when the Fortran model of how to do it right was
already some 30-yr in existence.
--![]()
...
> Just forget about the records I gave you and suppose a really simple case:
> Let the record be:
> 'ss45gg67tt'
>
> I want to have, after I textscanned it, the cell C so that:
> C(1)='ss' ;C(2)=[45]; C(3)='gg';C(4)=[67] and C(5)='tt'
>
> 45 and 67 should be read as floating number.
> The fortran equivalent would be (a2,f2,a2,f2,a2)
>
> Now suppose one field is missing and another is slightly different
> Let the record be:
> 'ss gg67 t'
>
> Then I want:
> C(1)='ss' ;C(2)=[]; C(3)='gg';C(4)=[67] and C(5)='t'
OK, that at least is understandable.
And, indeed, textscan() isn't smart enough (altho it is a little better
than fscanf() and friends). It _will_ parse the fixed fields if they're
all there and complete, but fails with the missing fields.
The test cases I had done I discover in going back only dealt with the
fixed width strings that can be separated (at least a _small_ step
forward) and I hadn't actually done the missing field on the expectation
of seeing an actual record to play with...
The really bizarre shortcoming is that even the ' t' subfield
fails--when C wants '%2s' it damn'd well just better be two characters
and even if 'delimiter','none' is in effect internally it still thinks a
leading blank is whitespace and ignores it so the conversion on the
field fails. It's truly hopeless.... :( How C ended up w/ such an
abomination is amazing when the Fortran model of how to do it right was
already some 30-yr in existence.
--