bugGNU Octave - Bugs: bug #38587, textread with incorrect result


bug #38587: textread with incorrect result

Submitted by:  Muhali <muhali>
Submitted on:  Mon Mar 25 12:27:16 2013  
Category: LibrariesSeverity: 3 - Normal
Priority: 4Item Group: Incorrect Result
Status: PostponedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Sun Nov 20 21:55:11 2016, comment #5:

This issue is still present in Octave 4.2.0.

Hartmut <hardy>
Sat Mar 30 19:33:08 2013, comment #4:

See also comment #17 in bug #38317

Philip Nienhuis <philipnienhuis>
Project Member
Tue Mar 26 18:17:54 2013, comment #3:

Of course it does; like textread.m, textscan.m pressently is a mere front end to strread.m and behaves essentially the same.

Philip Nienhuis <philipnienhuis>
Project Member
Tue Mar 26 08:04:27 2013, comment #2:

> The only solution would be a compiled (x)textscan as backend for textscan.m, textread.m and as a strread.m replacement

but note that textscan gives the same incorrect result for this example (foo.txt').

Muhali <muhali>
Mon Mar 25 20:01:27 2013, comment #1:

This might be impossible to fix with current strread.m

It's mere coincidence that strread.m gives identical results as ML while textread.m does not.

The underlying issue is that strread.m as it stands relies on identical number of fields (loosely defined as "something between delimiters") in all separate "lines" of a text file.
Now your example file contains an incomplete line (even completely empty), which breaks strread.m's parsing.
You could try with two empty lines see whether parsing gets in proper sync again.

In addition to the text file, textread.m silently feeds an endofline parameter (+ some other args) to strread.m which a.o. makes strread.m treat endofline characters somewhat different than other delimiters and/or whitespace. That's the cause of the different behavior you saw.

Due to some conference paper deadline (in addition to regular work) I won't have time to look into this until at least after the end of next week. But I fear there's little hope.

The only solution would be a compiled (x)textscan as backend for textscan.m, textread.m and as a strread.m replacement

Setting status to 'postponed" (might become "won't fix") and fixing other entries

Philip Nienhuis <philipnienhuis>
Project Member
Mon Mar 25 12:27:16 2013, original submission:

This may be related to bug #34734. If the file 'foo.txt' contains

then [a b] = textread("foo.txt", "%s%s") gives

a =
[1,1] = a
[2,1] =
[3,1] = b
b =
[1,1] = b
[2,1] = a
[3,1] =

Doing instead [a b] = strread ("a b\n\na b", "%s%s") gives

a =
[1,1] = a
[2,1] = a
b =
[1,1] = b
[2,1] = b

which is what ML gives in both cases.

Muhali <muhali>


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

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by muhali (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Mar 25 20:01:27 2013philipnienhuisPriority5 - Normal=>4
      Operating SystemGNU/Linux=>Any
      Summarytextread with incorect result=>textread with incorrect result

    Back to the top

    Powered by Savane 3.1-cleanup1