The Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Math Forum » Discussions » Software » comp.soft-sys.matlab

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: The function textscan
Replies: 9   Last Post: Mar 28, 2013 5:53 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]

Posts: 25
Registered: 10/3/11
Re: The function textscan
Posted: Mar 27, 2013 7:46 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

dpb <> wrote in message <kit8ad$9f$>...
> On 3/26/2013 4:56 PM, Steven_Lord wrote:
> > "dpb" <> wrote in message
> > news:kisv1h$4t2$
> >
> > *snip*
> >

> >> textread(), while deprecated by TMW and not as fully flexible as
> >> textscan() does have some benefits that aren't available otherwise the
> >> primary of which is that it returns "ordinary" double arrays instead
> >> of cell arrays only a la textscan(). That can often be a nice advantage.

> >
> > I agree that it can be an advantage. It can also be a complication.
> >
> > Without careful analysis of the TEXTREAD call, it can be difficult to
> > determine the types that the output arguments can have. It may even be
> > impossible if one or more of the inputs is user-specified at runtime.

> I suppose altho I must say I've never run into that limitation -- if it
> is necessary that the inputs be variable then that ought to be planned
> for in the app. In most instances, however (and I'd argue that it's the
> overwhelming majority of cases) the purpose is to read a fixed file
> format. That often is simply the case where an array is all one
> needs/wants and a cell is unneeded/unnecessary overhead.
> ...snip for brevity continuation of above thought...

> > The syntax for TEXTREAD also has another drawback: we can never add any
> > more output arguments with specific meanings. The syntax with (for
> > example) five data outputs and one "flag" output would look the same as
> > the syntax with six data outputs.
> >
> > On the other hand, TEXTSCAN returns one data output argument and
> > whatever additional output arguments we choose. It currently has a
> > second output argument named position that lets you read part of a
> > string or file and continue reading from where you ended up later.
> >
> > TEXTSCAN also returns a cell array as its first output. Always. That is
> > its documented behavior, and so if it doesn't then you're using a
> > version of TEXTSCAN that's shadowing the version shipped with MATLAB or
> > you've hit a bug. We know cell arrays have a steeper learning curve than
> > regular double arrays or even plain char arrays ('strings') as indicated
> > by plenty of questions in CSSM about cell array indexing [usually
> > dealing with the difference between C{1} and C(1).] But reading in files
> > written in arbitrary formats can be a challenge in general, and so we're
> > starting from a slightly higher point on the learning curve than if we
> > had, say, the PLUS function return cell arrays.
> >
> > The output type consistency argument and the output extensibility
> > flexibility are IMO good reasons to prefer TEXTSCAN to TEXTREAD in many
> > situations.

> The key point in all of the above is "many" situations. I don't and
> have never argued there isn't a place for textscan(); what I still argue
> for is that where there isn't any advantage in the cell because it is
> simply a set of numeric data then there should be a way to bypass the
> cell directly and that way shouldn't be deprecated or no longer fully
> supported.
> If it is, in TMW's opinion, desirable to have a different syntax to
> incorporate that then do so...

> >> I keep harping on the desirability of continuing to fully support
> >> textread(). Whether the message is being received by TMW is hard to
> >> tell--there is essentially no feedback other than in whatever it is
> >> they choose to release on the next release, unfortunately.

> >
> > Look at the Release Notes for MATLAB:
> >
> >
> >
> > Release R2012b, Language and Programming section, "Preservation of
> > string functions for backwards compatibility" item.
> >
> > We do listen. We occasionally even change our minds based on the
> > feedback we receive. :)

> Yeah, but we don't get that feedback typically until whatever is in the
> release is released--rarely does one hear back when one tosses a
> suggestion over the wall in whether it is a enhancement request or
> compatibility or whatever.
> It is good that at least sometimes what goes in does have at least some
> effect, certainly.
> --

Thank you for all the explanation above. I did not realize that I needed to reposition it.
And now I saw a lot of reasons to use the textscan that I hadn't idea before, I'm kinda of new using MATLAB to write scripts and I think I'll need all the help available rsrsrs..

Thanks for all.

Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2018. All Rights Reserved.