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, 20 Dec 2012 21:20:03 +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):

                Severity:              3 - Normal => 2 - Minor              

    _______________________________________________________

Follow-up Comment #5:

Just to get back to the original bug report: 
I don't see why a 'whitespace' parameter is used to essentially specify a
delimiter.

In both Octave (dev version) and ML r2012a the following works OK on the
example:

A = textscan (fid, "%s %s", "Whitespace", "", "delimiter", ";")

Note that

B = textscan (fid, '%s %s %s', 'Whitespace', ';')

won't work on the example as Octave cannot substitute empty values for fields
beyond an EOL on incomplete lines (L.1 contains just two fields). A compiled
textscan() could...
A way around that is to invoke textscan in two (or more) passes, each time
with a different format string, + format repeat count (1st pass) or
'headerlines' param (last pass) or both (intermediate passes, if present).

Ben, as to your observation:
<QUOTE>
whitespace=";" implies that spaces, tabs and such are not whitespace.
</QUOTE>
Correct. The default for whitespace (" \b\t" is replaced by a user-specified
value, as it should. 
But.... in L.s 124..125 of textscan.m, it also reads:
    ## If there is a string format AND whitespace value = empty,
    ## don't add a space (char(32)) to whitespace
This is based literally on TMW's on-line help for textscan.m. (see whitespace
section).

While I do think textscan.m's (or rather strread.m's) whitespace processing
can be improved, AFAICS the setup of the call to textscan by the OP was faulty
/ clumsy in the first place.

I tend to close this bug report with (in decreasing order of preference):
"Invalid" (faulty call to textscan), or 
"Works for me" (= with proper call to textscan), or 
"Fixed" (as it relates to an old textscan/strread version), or
"Won't fix" (I can't really guarantee that ;-) )
Who takes the pick?

I'll decrease priority in any event.

Off-topic: 
I just noted that TMW changed the behavior of textscan: specifying multiple
delimiter chars is now supposed to be in a cell array rather than as a
character string.


    _______________________________________________________

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]