Re: Textscan Stops for Missing Data

[Ozzy Lash]

On Sat, Aug 26, 2017 at 10:49 AM, PhilipNienhuis <address@hidden> wrote:

Ozzy:


Ozzy Lash wrote
> Have you tried setting the "WhiteSpace" option so that it doesn't include
> \t?  I see different behavior with that.  The only problem is, your file
> has a few lines that start with a tab, and that trows the processing off.
> If I get rid of those tabs, it reads 110 entries.
>
> The argument I used was "WhiteSpace", " \b\n\r"
>
> Reading the documentation is strread for I see the default is " \b\n\r\t"
> ,

Sorry but it looks like you're a bit confused?
strread.m isn't the engine behind textscan anymore.
Nowadays textscan is a separate, binary function and as such much faster
than the combo textscan.m+strread.m used to be.

Philip

Oops, It looks like you are correct.  I was originally trying the example using an old version, and looked at the m-file for textscan, and saw it used strread, however the example didn't work, so I switched to a machine that has a development version on it, and now the documentation for textscan shows the "Whitespace" documentation. 

My suggestion still stands, changing the value of "Whitespace" gives different behavior, and if the lines that have a tab as the beginning character are trimmed so that they don't start with a tab, I think the behavior is what the original poster wanted. The documentation for "Whitespace" in textscan is more clear to me:

"Whitespace"
          Any character in VALUE will be interpreted as whitespace and
          trimmed; The default value for whitespace is " \b\r\n\t" (note
          the space).  Unless whitespace is set to "" (empty) AND at
          least one "%s" format conversion specifier is supplied, a
          space is always part of whitespace.

I wonder if it would make sense to remove the "Delimiter" value from the "Whitespace" values.

Bill