RE: problems with latest strread (comma delimiters)

[krthie]

Hi Philip
> 
> If you do not specify a delimiter character in strread calls, any
whitespace
> character is supposed to be delimiter character. (Default whitespace = "
",
> "\n", "\t", "\r" & "b".)
> However, if you do specify a delimiter, only that delimiter char is
actually
> used and whitespace is simply ignored.
> 
> In your case,
> [a1, a2] = strread ("1,2\n3,4\n", '%f%f', 'delimiter', ",\n")
> works as desired.
>

OK. I understand this.(I'm not sure if that's how matlab works, but I cannot
check it as I don't have access to a license at the moment.)

I'd agree that white-space is not a delimiter, but that shouldn't mean that
we just gobble it up. For example, the following results are very surprising
in my opinion...

octave> [a1,a2]=strread("1     2, 3 4",'%f%f','delimiter',',')
a1 =  12
a2 =  34
octave> [a1,a2]=strread("1     2, 3 4",'%f%f','delimiter','t')
a1 =  1234
a2 = [](0x1)

> That it does work "OK" with textread and textscan is because these have a
> somewhat obscure option "endofline" (see help of those functions) whose
> default is to automagically include EOLs in the delimiter collection.
> 
<snip>
> FYI, as strread currently does the "low-level" work for textread,.you
could
> also call strread like this:
> [a1, a2] = strread ("1,2\n3,4\n", '%f%f', 'delimiter', ",", "endofline",
"\n")    #
> Note: undocumented
> 
<snip>

Ok. great. Thanks!

Kris

---

View this message in context: RE: problems with latest strread (comma delimiters)
Sent from the Octave - General mailing list archive at Nabble.com.