textscan trouble: starting file position on re-read

I'm trying to read a data file of integers. The file is formatted as follows:

 -112-999-999-999-555
 -999-999
 -777   0   0   0   0
    0  20
 -757  11   0   0   0
    0   0

There are 3 blocks of 7 numbers each.

I tried

fid=fopen('filename.txt')
textscan(fid,'%4d',7)

And got the following as expected.

-112
-999
-999
-999
-555
-999
-999

But then I issue &nbsp textscan(fid,'%4d',7) &nbsp again. I would expect to get the second block this time, but instead I get:

    2
    -999
    -999
    -999
    -555
    -999
    -999

It seems textscan started reading at the wrong place (not where it left off).

Any thoughts why it's doing this?

Thanks, David

[dpb]

Nope, seems fine here...

>> fid=fopen('chen.dat');
>> for i=1:3
disp(cell2mat(textscan(fid,'%4d',7,'collectoutput',1)).'),end
    -112      -999      -999      -999      -555      -999      -999
    -777         0         0         0         0         0        20
    -757        11         0         0         0          0        0
>> fid=fclose(fid);
>> type chen.dat
-112-999-999-999-555
-999-999
-777   0   0   0   0
  0  20
-757  11   0   0   0
  0   0
>>

Don't know what to tell you, sorry...

[David C]

Bug in R2014a. Tried the same code in R2011a and it works fine. Thanks dpb.

[David C]

How can this be reported to MathWorks?

[dpb]

http://www.mathworks.com/support/contact_us/index.html?s_tid=hp_ff_s_contact

[Patrick]

I ran into this same issue with R2013b.

Answer 1

[Image Analyst]

In your second call to textscan() your first argument is fww. What is that? Why are you not using fid like in the first call to textscan()????

[Image Analyst]

Make it easy for us to help you, not harder. Don't make us have to create a data file, just attach yours with the paper clip.

[David C]

It was a typo in my post. In my actual code the file identifier variable is consistent. In my comment above, I identified the issue as a bug with the textscan function in R2014a, as in R2011a it works as expected. Let me know if you think otherwise. Thanks.

[Image Analyst]

I was going to . I have R2014a. Read my comment above.

[David C]

Good suggestion. I did not realize there was an "attach" option. Thanks for the heads up.

[David C]

I changed some numbers for debugging purposes, but the format is still the same. Here you go.

[Image Analyst]

For some reason it's getting confused by all your numbers running together and being connected. If you just put a space in front of the minus signs, then it runs fine. I'm not exactly sure I'd call it a bug since in a text file there is supposed to be some separator between the numbers, unlike a binary file, but I admit it is a little confusing at first. If you pass it numbers like you're supposed to it works as expected.

[dpb]

That's still a bug imo...the counted field should take care of it.

That it works with the file as formatted in earlier release (R2012b) is also indicative I think. textscan is terribly complicated and has several warts related to, especially, fixed-width field processing it seems. I've submitted a couple other bug reports in the past on similar parsing problems. Perhaps in trying to fix one of those, they introduced another...

This thing about C being so dysfunctional with fixed-width fields on formatted input is a real pain. Why K&R introduced some of these "features" is beyond ken, especially since the Fortran FORMAT example was already there as a much better model.

[Stephen23]

Tested with MATLAB R2012b. I downloaded your data file filename.txt, and ran the following code:

>> fid = fopen('filename.txt');
>> A(1) = textscan(fid,'%4d',7);
>> A(2) = textscan(fid,'%4d',7);
>> fclose(fid);
>> [A{:}]
ans = 

        -100        -106
        -101         107
        -102         108
        -103           0
        -555           0
        -104           0
        -105          20

This seems to give the outputs you want.

[per isakson]

With 2014a

    ans =
            -100           0
            -101        -101
            -102        -102
            -103        -103
            -555        -555
            -104        -104
            -105        -105

was this ever reported?