[Octave-bug-tracker] [bug #51231] textscan skips line ending

[Philip Nienhuis]

Update of bug #51231 (project octave):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #2:

I am not sure this is a bug. I rather suspect you mix up the meaning of
textscan's format string and the number of data per line in a data file.

A format repeat count instructs textscan to invoke the *format string* the
specified number of times, no matter how many lines the format would cover.
(The format string may even cover just part of a "line" in a data file.)
IOW, the format repeat count does NOT specify to read the specified number of
lines.

FYI, textscan() interprets a data file as just one long sequence of characters
and has no notion of "lines" in a data file; line endings (EOL) are treated as
ordinary delimiters by default.

A textscan format string just specifies how many data fields are to be read
and turned into a corresponding number of output data columns. There is no
_implicit_ connection between number of data fields in the format string and
the number of data per line in the data file.
So in your example textscan does seem to do the right thing. It invokes the
format string once, and that format string tells textscan to read three data
fields and and return them in three separate output data columns.

Only if you'd specify a format specifier like '%*[^\n]' (= skip until the
first end-of-line after the last read data field) some notion of data file
lines comes in sight. But note that even in that case textscan may still read
several data lines per format string.

This is different than e.g., dlmread() that does process files line by line.

As I've maintained most of textscan.m and strread.m in the last years I feel
qualified to say that I'd rather expect the old textscan.m (or rather, its
work horse strread.m) to do it wrong.

A comparison with Matlab would help here. What does Matlab return?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51231>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/