Wed 26 Mar 2014 01:40:40 PM UTC, comment #2:
Confirmed, I hit a similar issue at work today.
BTW, the contents of the text file you attached differ from your bug report. But I don't think that matters.
Trying your example in Matlab neatly gives the output I suppose you expected (note I copied the file contents from your report, not your file):
Right, looks good. Now trying with two columns of text and a delimiter:
File contents:
Landmark-1 HHH
Landmark-2 HHH
Landmark-3 HHH
Landmark-4 HHH
Landmark-5 HHH
and moreover with a file containing:
1223_889&
123745==2515@3
ML gives:
...so I conclude that if Matlab's importdata() can't distill any numeric data from the file, it simply assumes it consists of all text and it'll return the lines it originally interpreted to be headerlines as file contents.
Little wonder as I think importdata.m is primarily meant to return numeric data, rather than text strings. You'd need to carefully read between the lines in the ML docs, but it's there.
You can see that if ML doesn't detect any numeric data, it simply ignores the explicitly specified delimiters in the file and returns a 1-column cellstr array.
I'll prepare a changeset later on (hopefully this week).
Another changeset is required for newly supported spreadsheet formats (a.o., gnumeric), some of which are now supported w/o external dependencies.
In the ML docs there's mention of another importdata output format, having headers above the data columns. I don't need it now, but if it's not too involved I'll have a go at that one as well.
--------------
OS set to "any" (I hit this on Windows);
Item Group => ML compatibility (as I think Octave isn't in error per se; it's just IMO inconsistent ML behavior we'd need to mimic)
|