Drexel dragonThe Math ForumDonate to the Math Forum



Search All of the Math Forum:

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


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

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 ]
Steven Lord

Posts: 17,944
Registered: 12/7/04
Re: The function textscan
Posted: Mar 26, 2013 5:56 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply



"dpb" <none@non.net> wrote in message news:kisv1h$4t2$1@speranza.aioe.org...

*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. This
means that when you call TEXTREAD, you MUST check the type of the returned
variables before you use them, or risk your code throwing an error in a case
where you assumed the output was a char array but it was a cell array
containing char arrays instead.

switch classOfFirstOutput
case 'double'
% do something
case 'char'
% do something else
case 'cell'
% do a third thing
end

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.

> 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:

http://www.mathworks.com/help/matlab/release-notes.html

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. :)

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com




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

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.