MATLAB vs. GNU Octave Textscan disparity

Question

I wish to read some data from a .dat file without saving the file first. In order to do so, my code looks as follows:

urlsearch= 'http://minorplanetcenter.net/db_search/show_object?utf8=&object_id=2005+PM';
url= 'http://minorplanetcenter.net/tmp/2005_PM.dat';

urlmidstep=urlread(urlsearch);
urldata=urlread(url);

received= textscan(urldata , '%5s %7s %1s %1s %1s %17s %12s %12s %9s %6s %6s %3s ' ,'delimiter', '', 'whitespace', '');
data_received = received{:}

urlmidstep's function is just to do a "search", in order to be able to create the temporary .dat file. This data is then stored in urldata, which is a long char array. When I then use textscan in MATLAB, I get 12 columns as desired, which are stored in a cell array data_received.

However, in Octave I get various warning messages: warning: strread: field width '%5s' (fmt spec # 1) extends beyond actual word limit (for various field widths). My question is, why is my result different in Octave and how could I fix this? Shouldn't Octave behave the same as MATLAB, as in theory any differences should be dealt with as bugs?

Surely specifying the width of the strings and leaving both the delimiter and whitespace input arguments empty should tell the function to only deal with width of string, allowing spaces to be a valid characters.

Any help would be much appreciated.

score 2 · Answer 1 · answered Jul 14 '15 at 12:11

I thinhk textscan works differently in MATLAB and Octave. To illustrate let's simplify the example. The code:

test_line = 'K05P00M  C2003 01 28.38344309 37 57.87 +11 05 14.9                n~1HzV645';
test = textscan(test_line,'%5s','delimiter','');
test{:}

will would yield the following in MATLAB:

>> test{:}

ans = 

    'K05P0'
    '0M  C'
    '2003 '
    '01 28'
    '.3834'
    '4309 '
    '37 57'
    '.87 +'
    '11 05'
    '14.9 '
    'n~1Hz'
    'V645'

whereas in Octave, you get:

>> test{:}
ans =
{
  [1,1] = K05P0
  [2,1] = C2003
  [3,1] = 01
  [4,1] = 28.38
  [5,1] = 37
  [6,1] = 57.87
  [7,1] = +11
  [8,1] = 05
  [9,1] = 14.9
  [10,1] = n~1Hz
}

So it looks like Octave jumps to the next word and discards any remaining character in the current word, whereas MATLAB treats the whole string as one continuous word.

Why that is and which is one is correct, I do not know, but hopefully it'll point you in the right direction for understanding what is going on. You can try adding the delimiter to see how it affects the results.

MATLAB vs. GNU Octave Textscan disparity

1 Answers1