RE: problems with latest strread (comma delimiters)

[PhilipNienhuis]

krthie wrote:
> 
> 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.)
> 

Maybe, but if ML works otherwise, its behavior would be at variance with its
own docs.
Wouldn't surprise me, BTW.



> I'd agree that white-space is not a delimiter, but that shouldn't mean
> that
> we just gobble it up. 
> 

So, what else should happen with whitespace in your opinion?



> 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
> 

Here you don't redefine whitespace, so spaces are gobbled. Should be OK,
IMO.



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

Yes, this doesn't look completely right. Some warning about the comma might
be expected.

Could you please file a bug report for this?

I'll have a look into it. I do have a vague idea of where to look. It is a
bit complicated as in the end this boils down to behavior of str2double(). 
(FYI, it is str2double ({'1 2, 3 4'}) that yields 1234)
But I can't do much computer work lately due to some physical issues, so
you'll have to wait, perhaps several weeks :-(

Philip


--
View this message in context: 
http://octave.1599824.n4.nabble.com/problems-with-latest-strread-comma-delimiters-tp3913839p3918011.html
Sent from the Octave - General mailing list archive at Nabble.com.