octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #37961] textscan : whitespace specification do


From: Ben Abbott
Subject: [Octave-bug-tracker] [bug #37961] textscan : whitespace specification doesn't work
Date: Tue, 25 Dec 2012 03:44:51 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Follow-up Comment #7, bug #37961 (project octave):

Running either Octave's default or stable branch, the original example gives
the error below.


warning: strread: unable to parse text or file with given format string


Matlab gives the same result for FMT = "%s;%s" and FMT = "%s %s".  It is the
first that gives produces the error for Octave.  Matlab's result is below.


A{1}

ans = 

    'XQPCTick'
    '1552111181823'
    '1552327767233'
    '1552570758808'
    '1552819036603'
    '1553037382424'
    '1553238114161'
    '1553456459982'
    '1553687128680'
    '1553905469514'
    '1554100925005'

A{2}

ans = 

    'Tag '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '
    'G8 Throw '


WIth FMT = "%s %s", neither Octave's stable and default branch throws an
error, but each return the same incorrect result.


A = 
{
  [1,1] = 
  {
    [1,1] = XQPCTick
    [2,1] = 1552111181823
    [3,1] = Throw
    [4,1] = G8
    [5,1] = 1552570758808
    [6,1] = Throw
    [7,1] = G8
    [8,1] = 1553037382424
    [9,1] = Throw
    [10,1] = G8
    [11,1] = 1553456459982
    [12,1] = Throw
    [13,1] = G8
    [14,1] = 1553905469514
    [15,1] = Throw
    [16,1] = G8
  }
  [1,2] = 
  {
    [1,1] = Tag
    [2,1] = G8
    [3,1] = 1552327767233
    [4,1] = Throw
    [5,1] = G8
    [6,1] = 1552819036603
    [7,1] = Throw
    [8,1] = G8
    [9,1] = 1553238114161
    [10,1] = Throw
    [11,1] = G8
    [12,1] = 1553687128680
    [13,1] = Throw
    [14,1] = G8
    [15,1] = 1554100925005
    [16,1] = Throw
  }
}


It looks to me as if the problem is with strread(). Looking over strread(),
the problem seems to due to two features of the implementation.

0 trread() ultimately converts all "whitespace" to char(32).  This will lead
to problems reading strings that should include spaces.
0 The current implementation also trims the input string of spaces in a few
locations.

The code responsible for parsing the string is complex and difficult for me to
follow.  There may be other problems there.




    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]