Thu 23 Nov 2017 11:24:21 PM UTC, comment #6:
If this is not a regression, and it involves deep changes to the textscan code, then it is not appropriate for the stable branch and 4.2.2 release. The more experimental work to add new features, including better compatibility, belongs on the development branch.
|
Wed 22 Nov 2017 01:14:28 PM UTC, comment #5:
Please disregard comment #3, I've opened a new item for it as suggested by comment #4, available here: https://savannah.gnu.org/bugs/index.php?52479
|
Tue 21 Nov 2017 09:38:47 PM UTC, comment #4:
Actually, I think this (#3) may be a different bug, but in the same area of code. I believe that bug is quite simply relative to the initial bug. It looks like the scanning routines all do skipping of white space in some form:
However, at the instantiation, the default white space includes the \t character:
What needs to be done is remove any delimiters from the whitespace string. That is, if the user selects
as you've done, then that character should be subtracted from the string.
We should probably create another bug report for this if there isn't one already.
|
Tue 21 Nov 2017 12:14:05 PM UTC, comment #3:
I think a found a related bug:
does not have the same output on Octave 4.0.3 and 4.2.1.
Version 4.0.3 matches MatLab's (v2017a) interpretation.
With v4.0.3:
With 4.2.1:
|
Sun 26 Mar 2017 01:54:56 AM UTC, comment #2:
I can describe what is wrong (fixing is another matter).
There is a function called textscan::read_format_once() which reads one line of of delimited fields, and this is in a loop until either N-times or indefinite (-1). The code breaks out of that loop if there was an error. There is an error, which is "nothing worked", but it is a bogus error because in fact there were two successful reads on the first line.
And that is what is missing from the code. There should be either some return value, or some means of deducing that textscan::read_format_once() did actually do something. Instead, the decision is solely based upon is.fail(). So, yes there was a fail (i.e., the third element of '2,1,'), but it's also true there were some successes (and one might even want to consider the NaN a success).
Simply oversight, but this goes pretty deep into multiple function calls, so I think this one would take time to fix and is a summer project sort of thing. NaN needs to be handled properly and some means of avoiding the bogus error needs to be implemented.
|
Tue 07 Mar 2017 09:13:32 PM UTC, comment #1:
Confirmed in 4.3.0+ & checked with Matlab r2017a prerelease.
|
Tue 07 Mar 2017 05:30:00 PM UTC, original submission:
textscan seems to ignore the content of the scanned text after an empty line
matlab:
octave:
|