octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #41579] textscan: file offset after partial re


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #41579] textscan: file offset after partial read differs from Matlab
Date: Tue, 24 Oct 2017 15:53:29 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48

Follow-up Comment #15, bug #41579 (project octave):

Dan,
Before venturing further I think I might try similar tricks with whitespace
and EOL settings in Matlab as I did in comment #12, with text and numeric
data. But I'm unsure if I have time for that the next days.

FYI, I took up textscan.m / textread.m / strread.m some years ago and tried to
make them as much Matlab-compatible as possible, based on a lot of
observations of Matlab behavior at the time by me and several others, and
given (Octave-)strread's limitations.
The result is that in Octave's still existing strread.m, which used to be
called by (now removed) textscan.m, it works as follows:

1. endofline character is first added to the delimiter collection

2. ...and removed from the whitespace collection if present there (strread.m
by default contains " \r\n\b\t").

Now, endofline may not be a "regular" delimiter but Matlab surely treats it as
such when reading multiple lines. Only if set to "" (empty) it is ignored, but
then again not when reading numeric data.
Maybe the only difference in the examples I gave is that regular delimiters
after the last read field are skipped but just not endofline. But when reading
continues, endofline seems to be treated as leading whitespace (I have to
confirm the latter).

And then there is the thing that whitespace is treated differently when
reading text, than when reading numeric data.
Multiple whitespace incl. endofline is usually collapsed, multiple delimiters
not. AFAIK when MultipleDelimsAsOne is specified, endofline preceding or
following a delimiter is is ignored in the collapse action (I have to verify
that too).

So endofline may be treated as whitespace and/or as delimiter, depending on
context.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]