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

 
 

bug #38587: textread with incorrect result

Submitter:  Muhali <muhali>
Submitted:  Mon 25 Mar 2013 12:27:16 PM UTC
 
Category:  Libraries Severity:  3 - Normal
Priority:  4 Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Thu 26 Aug 2021 09:07:40 PM UTC, comment #6: 

textread.m and strread.m are legacy functions now so I don't think that there's any chance this bug will be fixed.

Closing report.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 20 Nov 2016 09:55:11 PM UTC, comment #5: 

This issue is still present in Octave 4.2.0.

Hartmut <hardy>
Sat 30 Mar 2013 07:33:08 PM UTC, comment #4: 

See also comment #17 in bug #38317

Philip Nienhuis <philipnienhuis>
Project Member
Tue 26 Mar 2013 06:17:54 PM UTC, 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 26 Mar 2013 08:04:27 AM UTC, 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 25 Mar 2013 08:01:27 PM UTC, 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 25 Mar 2013 12:27:16 PM UTC, original submission:  

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

a b

a b

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by muhali (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-26 philipnienhuis StatusPostponed Wont Fix
        Open/ClosedOpen Closed
    2013-03-25 philipnienhuis Priority5 - Normal 4
        StatusNone Postponed
        Operating SystemGNU/Linux Any
        Summarytextread with incorect result textread with incorrect result

    Back to the top


    Powered by Savane 3.9