importdata skips the last few rows?

Hello all. I was using importdata in my code to bring in some matrices. I hadn't tested the code in quite some time, but I just upgraded from r2011a to r2012a and then ran it. Apparently importdata is now misbehaving. Whenever I try to do

>> data = importdata('file.txt')

where file.txt is a 360x720 ASCII file (generated from Matlab a while back using

>> save('file.txt','variable','-ASCII')

I get a variable that is 348x720:

>> size(data)

ans =

   348   720

This happens with other 360x720 ASCII files as well, although for some of them I only get 347 rows. What do you think is going on? Thanks in advance!

PS: Here is a link to an example 'file.txt' this happens with.

[Sean de Wolski]

Does it fail in both 11a and 12a? Are there any empty lines or invisible ASCII that could be causing it to choke?

[Sam]

I deleted r2011a after installing r2012a so I can't be sure at this point, but I certainly never ran into this issue when using r2011a before.

[Sam]

Also, no, there are no empty lines or anything that I can see using a text editor.

Answer 1

[Geoff]

That's odd... Confirmed in my own 2012a.

It appears to be trimming all the entirely NaN rows from the end of your data.

I replaced line 348 with line 349, and confirmed the result is 347 rows long. Then I set the first element in line 360 to a non-nan value, and the result was 360 rows long.

I think this is stupid behaviour to have in a function, but nevermind.

Given that the files were created with save, you should do this instead:

data = load('file.txt', '-ASCII');

[Jan]

LOAD('-ascii') is exactly what happens in 2009a:importdata. Is this function still an M-file in 2012a, which can be debugged?

[Geoff]

In fact, I would submit a bug report to MathWorks on this issue if it indeed has been introduced in 2012a (can someone confirm in 2011a or 2011b?). There is no mention of this behaviour in the documentation.

I suspect that it might not be handling 'NaN' explicitly... It will simply give a NaN if the string is anything other than a number. So in that case, the last VALID input was on line 348, which contained numbers. Still... I would perceive that truncation as 'nannying'.

[Geoff]

@Jan : Oh, I had a look and found this:

if ~isempty(numericData)

numericData = TrimTrailing(@(x)(isnan(x)), numericData);

end

[Sam]

Geoff, using "load" as you suggest does the trick. I will be submitting a bug report… I think that at the very least that behavior in "importdata" needs to be documented and optional. Thanks for your help!