[Octave-bug-tracker] [bug #34734] problems with latest strread (newlines, spaces and commas)

[Philip Nienhuis]

Update of bug #34734 (project octave):

                  Status:                    None => In Progress            
             Assigned to:                    None => philipnienhuis         

    _______________________________________________________

Follow-up Comment #1:

(Devs: are bugs in script files "libraries" or "interpreter" bugs?)

Several more comparitive tests w ML & Octave led to the conclusion that ML
documentation is not very clear about the exact behavior of strread &
textscan. In some instances ML even deviates from its documented behavior.
There's still no agreement as to what ML behavior should be considered a bug,
or just a case of poor documentation. See this thread:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-October/025443.html

I know how to fix your case 1 (it'll incur another speed penalty BTW), but I
doubt if every ML corner case behavior can be mimicked; this is largely due to
the way Octave's strread.m has been written.

In your second case you haven't specified a comma as delimiter. The bug here
is actually due to str2double()  (Happens in your last case as well)

In your final example, "n" is no "record delimiter" as strread reads from a
string, not a text file.
In fact, "n" (like " ", "t", "b" and "r") should rather have been included in
the delimiter set *for numeric fields only* by default. *That* (rather
obscurely documented ML behavior) is the exact bug I'm going to (try to) fix.

Note that 3.2.4 strread has the "inverse bug" when reading a string using "%s"
format conversion specifiers. In that case space should NOT be part of the
delimiter set for strings.

Thx for reporting.


    _______________________________________________________

Reply to this item at:

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

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