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: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #37961] textscan : whitespace specification doesn't work
Date: Thu, 27 Dec 2012 23:14:23 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6

Update of bug #37961 (project octave):

                  Status:         Patch Submitted => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #11:

Your analysis is spot-on:

>> ver
------------------------------------------------------------------------------------------------
MATLAB Version: 8.1.0.47 (R2013a)
:
<snip>

>> A = textscan ('XQPCTick;Tag', '%s;%s')
A = 
    {1x1 cell}    {0x1 cell}
>> A{:}
ans = 
    'XQPCTick;Tag'
ans = 
   Empty cell array: 0-by-1


while Octave with 3.7.0+ textscan/strread gives:

octave.exe:1> A = textscan ('XQPCTick;Tag', '%s;%s')
warning: implicit conversion from scalar to sq_string
warning: Ambiguous '☺' specifier next to literal in column
A =
{
  [1,1] =
  {
    [1,1] = XQPCTick;Tag
  }
  [1,2] = {}(0x1)
}


There is something fishy in Octave but I cannot easily see where the first
warning comes from. I've fixed the second warning to be more clear
(http://hg.savannah.gnu.org/hgweb/octave/rev/4294430ef736).
Anyway the comments (that I added long time ago) in strread.m around L.600 do
confirm your analysis: when using a "%s" format you can't expect Octave, or
ML, to reliably distinguish the corresponding text field from an immediately
following literal.

That, plus different results in r2012b than in r2013a for your second call is
adequate to close this bug with "Invalid".

BTW your patch does give some useful hints on how to process repeated
whitespace in %s fields. If I get time & need it myself, and jwe doesn't beat
me with textcan.cc, I might have another look at it.

Let's leave it to Jordi to decide if he wants a more robust
strread/textscan/textread for upcoming 3.6.4.

    _______________________________________________________

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]