octave-maintainers
[Top][All Lists]
Advanced

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

advice / help needed for reading formatted text (textscan, strread, & te


From: John W. Eaton
Subject: advice / help needed for reading formatted text (textscan, strread, & textread)
Date: Mon, 25 Oct 2010 02:20:59 -0400

On 25-Oct-2010, Ben Abbott wrote:

| The function textscan, strread, and textread currently are not fully 
compliant with ML. They each need expanded support of formats.
| 
| ML    supports the following format types; %d, %u, %f, %s, %q, %c, %[…], %[^…]
| 
| In addition it supports skipping entries, "%*f", and specifying precision, 
"%12.5f"

The scanf functions already handle all of the format specifiers above
except for %q and bit-widths for %u and %d conversions.  I suppose
adding bit-width conversion specifiers (%d8, %d16, %d32, %d64, %u8,
%u16, %u32, %u64) would not be too hard.  Adding %q might not be too
hard either.  Exactly how is it supposed to work?  Does it mean to
match something like

  [:space:]*"[^"]*"

and return everything between the two ""?  Is it an error to have a
newline embedded in the quoted string?

| ... and have "c" be returned as a [Nx5] cell array, where the "%s", "%c", and 
"%[TF]" entries are cell-strings and the other cell entries are numeric.

I think we need a new function other than the scanf functions to
return values in a cell array.  But rather than writing it from
scratch, it should probably be based on the
octave_base_stream::do_scanf function in oct-stream.cc.  I guess we
would need to handle the %{ud}{8,16,32,64} and %q specifiers in the
scanf_format_elt class and the octave_base_stream::do_scanf function.
When called by the scanf functions, these extra format specifiers
should be disabled.  I think that would be as simple as not
recognizing them when constructing the scanf_format_elt object from
the given format string and there would not have to be specific checks
in the do_scanf function.  There would also need to be an option to
gather the output values in a different way so they could be returned
as a cell array.  I could probably help with implementing this.

jwe



reply via email to

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