[Octave-bug-tracker] [bug #38587] textread with incorrect result

[Philip Nienhuis]

Update of bug #38587 (project octave):

                Priority:              5 - Normal => 4                      
                  Status:                    None => Postponed              
        Operating System:               GNU/Linux => Any                    
                 Summary: textread with incorect result => textread with
incorrect result

    _______________________________________________________

Follow-up 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


    _______________________________________________________

Reply to this item at:

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

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