Re: Improving strread / textread / textscan

[PhilipNienhuis]

bpabbott wrote:
> 
> On Oct 31, 2011, at 4:54 PM, PhilipNienhuis wrote:
> <snip>
>> As you can see in example 6, this is not what happens. At least the
>> trailing
>> space is preserved.
>> 
>> Anyway, ML seems to have a consistent (but obscurely documented) rule
>> about
>> parsing numeric versus string fields depending on delimiter/whitespace
>> values. That might render implementing it in Octave a bit easier.
>> 
>> Philip
> 
> Good catch. So, for delimited character fields, the leading whitespace is
> trimmed and the trailing whitespace is preserved.
> 

Sure.
But what do we do with it?

As to strread: from the ML docs for strread, in the format conversion
specifiers table:
  "   %s   Read a white-space separated string.    "

So ML-strread's actual behavior (i.e., including spaces in text fields)
seems clearly at variance with ML's own docs. Unless I overlook something?

As to textscan, this exact behavior is not covered in the ML docs (...).

I perceive these simply as ML bugs:
- Including enclosed spaces in text fields;
- Preserving trailing spaces with text fields. 
I'm not convinced that we should blindly follow ML here.
Any other opinions, please?


BTW I'm thinking more and more of adding a "-braindead" parameter to
strread.m to actually invoke the planned patched code.....

Philip


--
View this message in context: 
http://octave.1599824.n4.nabble.com/Improving-strread-textread-textscan-tp3931190p3965650.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.