octave-maintainers
[Top][All Lists]
Advanced

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

Re: strread.m


From: John W. Eaton
Subject: Re: strread.m
Date: Tue, 2 Aug 2011 20:43:13 -0400

On  3-Aug-2011, Philip Nienhuis wrote:

| John W. Eaton wrote:
| 
| > to have many more format options.  So why handle textscan with
| > strread?
| 
| Because Octave's textscan has been written that way.
| Perhaps the thinking was along the lines of "there's a scripted 
| strread.m available; a binary strread replacement can easily be swapped 
| in as soon as there is one."
| Ben might be able to tell you more (he is the author of textscan).

| Anyway, would there be a problem in extending (parts of) Octave's 
| strread (and textread) versatility beyond that of Matlab's? I guess not.

The Matlab docs say that textscan is intended to replace both textread
and strread.  And since textscan seems more versatile than either of
the obsolete functions, it seems better to me to write a complete
textscan implementation in C++ and then perhaps try to use that to
implement strread and textread.  Though I think there may be problems
even with that.  For example, what does Matlab do with

  [a, b] = strread ('1 8 1', '%u8 %u');

vs

  a = textscan ('1 8 1', '%u8 %u');

?  I expect that in the first case, it will skip reading the 8 and
return a and b as double values, while in the second it will read all
three values and return the first and third as uint8 values and the
second as a uint32 value.  If so, then I don't know how you would take
the format that is passed to strread and convert it to something that
textscan can use to obtain the same result as strread.

My plan was to base textscan on scanf (see oct-stream.{h,cc}), but to
use a separate class to represent the format specifiers since they do
not overlap exactly with scanf.  Given that scanf already provides an
example of how to do this sort of thing, I don't think it would be
terribly hard to do, but it would take some time as textscan is a
complicated function and there are a few new twists, like reading
complex numbers and allowing the user to specify things like the
character used for exponents (though I think things like that could be
omitted in the initial implementation).

jwe


reply via email to

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