Re: advice / help needed for reading formatted text (textscan, strread, & textread)

[Ben Abbott]

On Oct 25, 2010, at 1:20 AM, John W. Eaton wrote:

> 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

John, reading this again it looks to me like someone needs to take the lead. 
Give my lacking for c/c++ skill, should I enter a "new feature" request in the 
tracker?

Ben