octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #52867] textscan produces an incorrect cell ar


From: Pedro Pena
Subject: [Octave-bug-tracker] [bug #52867] textscan produces an incorrect cell array
Date: Fri, 12 Jan 2018 14:32:10 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0

Follow-up Comment #3, bug #52867 (project octave):


The cell array structure is good, so I agree it's
likely being read incorrectly. 

In the submitted example a text file is prcoessed by textscan.
This text files contains text representing variable names and the values
assigned to the variable names.
textscan should produce a cell matrix containing variable names along with the
values for those variables. 

cruiseVars{1} should contain the all of the variable names(left of "=").
cruiseVars{2} should contain the values assigned to the variables(right of
"=").

This makes it easy to search for values using the variable name.

For example, say I want to retrieve the value assigned to variable "cruise_id"
after cruiseVars is created.


>> X = strfind(cruiseVars{1},'cruise_id');
>> i=find(~cellfun(@isempty,X),1);
>> cruiseVars{2}{i}
ans = AB1705


I have a function that does this.
https://github.com/pedrolpena/visbeck_ladcp_processing/blob/master/m/misc/get_cruise_variable_value.m

 
In the above example "AB1705" is indeed the value assigned to variable
"cruise_id" this was taken from the following line in the text file.

cruise_id=AB1705
cruise_id_prefix=
cruise_id_suffix=


However when I attempt to extract the value for "cruise_id_prefix", the value
returned is "cruise_id_suffix", which
means that the data that should be contained in cruiseVars{1} has been placed
in cruiseVars{2}. It's as if textscan  "sees" the next line
as being after the "=" on the same line.

This following is what it looks like to textscan.

cruise_id_prefix=cruise_id_suffix


It looks like the CRLF is being seen as another delimiter (I imagine it does
use it as a new line delimiter).
Maybe there is some logic that applies the newline delimiter to the delimiter
used in the text tokenization process?
A newline detection next to a delimiter detection issue?


With this in mind I tried one of your test's and I replaced the blank with a
character and this made it work as expected even though it failed for you.


cruise_id=AB1705
cruise_id_prefix=a
cruise_id_suffix=b


the values on the left of the "=" are placed in cruiseVars{1} and the values
on the right of "=" are placed in cruiseVars{2} as it should.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52867>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]