[Octave-bug-tracker] [bug #33875] textscan: missing format conversion specifiers

[Philip Nienhuis]

URL:
  <http://savannah.gnu.org/bugs/?33875>

                 Summary: textscan: missing format conversion specifiers
                 Project: GNU Octave
            Submitted by: philipnienhuis
            Submitted on: Thu 28 Jul 2011 08:17:08 AM CEST
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: None
             Assigned to: None
         Originator Name: Philip Nienhuis
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.4.2
        Operating System: Any

    _______________________________________________________

Details:

(known issue, entered in bug tracker so we don't forget after bugs #31380,
#33680, #33536, #32720, #31778 and maybe a few others have been fixed lately)

%d8 %d16 %d32 %d64
%f32 %f64
%u8 %u16 %u32 %u64   (unsigned integers)

ML reads integers by default as 32bit, floats as 64bit. Provisionally Octave
reads all these values as doubles.
Workaround:
Type casting -if needed- can be done on textscan's output.
Precision digits trailing the format specifier (e.g., "32", "64") have to be
removed from the input format string as Octave will treat them as literals.

%n
These are read by Octave as if %f was specified (doubles)

%q        (read string between double quotes)
%c        (read single character including delimiters)
%[...]    (patter matching)
%[^...]           ''
There is no workaround for these.
To some extent %c can be replaced by %1s
In simple cases %q might be replaced by clever use of " literals.

Some background:
Octave processes text files by (in principle) reading them completely and then
processing the read text string by parsing it into data columns according to
the layout of the format string. Reading then proceeds by transforming the
columns into the desired format (class).
Any format conversion specifier for which it isn't known in advance where the
actual data field limits (~delimiters) appear on a line (which may be
different for each line in the file) will break Octave's column parsing
scheme.
This applies to %q, %c and especially  %[..], %[^..]





    _______________________________________________________

Reply to this item at:

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

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