bugGNU Octave - Bugs: bug #45712, strread bug when ignoring a string


bug #45712: strread bug when ignoring a string

Submitter:  None
Submitted:  Fri 07 Aug 2015 12:47:07 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  philipnienhuis
Originator Name:  Francesco Potortì Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.0.0
Operating System:  * Any
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Sun 16 Aug 2015 02:41:19 PM UTC, comment #11: 

OK, I've pushed a cs on stable improving (hopefully) the usage of whitespace and delimiter params:

Philip Nienhuis <philipnienhuis>
Project Member
Sat 15 Aug 2015 01:29:21 PM UTC, comment #10: 

The meaning of "trimmed" is not clear to me.  If it means that consecutive consecutive whitespaces are collapsed to one, I think this should be explicitly stated, more so as it looks strange to me that whitespaces are collapsed in the presence of %s specifiers.

Thank you for following up on this. By the way, I may not be able to follow this discussion in the next couple of weeks.

Francesco Potortì <pot>
Sat 15 Aug 2015 01:00:20 PM UTC, comment #9: 

Turns out is is mentioned in the texinfo help, but maybe not so clear.
What about the following?

          Any character in VALUE will be used to split STR into words
          (default value = any whitespace).  Note that whitespace is
          implicitly added to the set of delimiter characters unless a
          "%s" format conversion specifier is supplied; see "whitespace"
          parameter below.  The set of delimiter characters cannot be
          empty; if needed Octave substitutes a space as delimiter.
          Any character in VALUE will be interpreted as whitespace and
          trimmed; the string defining whitespace must be enclosed in
          double quotes for proper processing of special characters like
          "\t".  The default value for whitespace is " \b\r\n\t" (note
          the space).  Whitespace is always added to the set of
          delimiter characters UNLESS at least one "%s" format
          conversion specifier is supplied; in that case only whitespace
          explicitly specified in "delimiter" is retained as delimiter
          and removed from the set of whitespace characters.  See also
          the "delimiter" parameter.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 15 Aug 2015 08:43:52 AM UTC, comment #8: 

Sure, I agree it would be helpful. But because large parts of whitespace/delimiter behavior in Matlab is un-/poorly documented it would become a long-winding and perhaps even ambiguous explanation.
I'll think about it.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 14 Aug 2015 04:21:56 PM UTC, comment #7: 

Would it be possible to clarify the description?  I would propose a text myself, but in fact I have not understood what should be changed. Maybe a concise version of your explanation would do?

Francesco Potortì <pot>
Fri 14 Aug 2015 03:38:46 PM UTC, comment #6: 

I've pushed a slightly modified cs (simplified test) here:


closing report.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 13 Aug 2015 08:20:13 PM UTC, comment #5: 

As to whitespace, that's a bit of an opaque issue.
From what I understand, if you do not specify a value for it, whitespace is usually added to the delimiters, unless a "%s" specifier is in the format string. See here:

Indeed, first of all multiple consecutive whitespace is usually collapsed. To some extent even "trimmed", if there's an adjacent delimiter.
Delimiters aren't collapsed, unless param "multipledelimsasone" is given with value true.
The functional distinction/relation between delimiters and whitespace is more complicated than described above and poorly documented.

Next, the string is split on delimiter occurrences.
The next step then in strread.m is trying to match the format string to the (usually first line of the) data. That serves as a first check but also inits several variables needed for ensuing steps.
In those further steps, a.o., fields immediately bordering literals and other fields are separated (e.g., "...1.5abc..." with fmt specs "...%f%s..." or "...%fabc..."). Think of ~ "virtual delimiters".

All in all the code is quite messy, but most of that is due to the way strread.m has been vectorized to the limit.
We do need a binary replacement; it was thought a binary textscan() could replace strread.m's innards but no one has come up with a working function yet.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 13 Aug 2015 12:36:55 PM UTC, comment #4: 

Thanks. I would also appreciate a clarification of the meaning of the "whitespace" parameter.

I understand that the first step in parsing is "collapsing to a asingle space" (not "trimming") all sequences of whitespace characters.  Then separators are searched and words identified.

But I am just guessing, and I suspect the guess is not accurate.

Francesco Potortì <pot>
Sun 09 Aug 2015 09:31:43 PM UTC, comment #3: 

Easier than I figured, luckily.

Patch attached. I'll push to stable (as this is a mere bug fix) within a few days if no one objects.

(file #34615)

Philip Nienhuis <philipnienhuis>
Project Member
Sat 08 Aug 2015 09:22:14 PM UTC, comment #2: 

Matlab r2015b prerelease doesn't need the whitespace parameter.

I'm not sure if this is easy to fix, but I'll have a look one of these days (if someone else doesn't beat me).

At least there is a workaround.

OS->Any, Release->dev

Philip Nienhuis <philipnienhuis>
Project Member
Fri 07 Aug 2015 04:30:18 PM UTC, comment #1: 

Did you want to get this?

>> [a c d] = strread("14 :5 z:11:-15:1", "%f%*s%f%f%*", 'delimiter', ":", "whitespace", "")
a =  14
c =  11
d = -15

Philip Nienhuis <philipnienhuis>
Project Member
Fri 07 Aug 2015 12:47:07 PM UTC, original submission:  

This is correct:

>> [a b c d] = strread("14 :5 z:11:-15:1", "%f%s%f%f%*", 'delimiter', ":")

a =  14
b =
  [1,1] = 5 z
c =  11
d = -15

Now trying, and failing, to ignore the second word:

>> [a c d] = strread("14 :5 z:11:-15:1", "%f%*s%f%f%*", 'delimiter', ":")

a =
c = NaN
d =  11

strread reads 14, then reads "5" and "z" as two different words, using space as a delimiter rather than colon.

Maybe this has to do with the string beginning with a digit, or containing a space, sorry, did not investigate further.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #34615:  bug45712.cs added by philipnienhuis (1KiB - text/x-csharp)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pot (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-08-14 philipnienhuis StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Releasedev 4.0.0
    2015-08-09 philipnienhuis Attached File- Added bug45712.cs, #34615
        StatusConfirmed Ready For Test
    2015-08-08 philipnienhuis StatusNeed Info Confirmed
        Assigned toNone philipnienhuis
        Release4.0.0 dev
        Operating SystemGNU/Linux Any
    2015-08-07 philipnienhuis StatusNone Need Info

    Back to the top

    Powered by Savane 3.9