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