Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
textread vs. textscan
379 views
Skip to first unread message
Steven
Jun 29, 2012, 4:09:07 PM6/29/12
to
I have code that uses the following textread function to read from a text file:
[t, node, xr, z, h, p, thet, sat, temp, vx, vz, et] = textread(...
'obsPoints.out','%f %f %f %f %f %f %f %f %f %f %f %f',3,'delimiter','',...
'headerlines',3)
This works fine to read the text file, but when I replace "textread" with "textscan", leaving everything else exactly the same, I get an error message:
??? Error using ==> textscan
Too many output arguments.
It looks to me like textscan and textread follow exactly the same format, so can someone help me understand why this code works with textread but not with textscan? I'm trying to update this code and, as the documentation for textread suggests, use textscan instead of textread.
[t, node, xr, z, h, p, thet, sat, temp, vx, vz, et] = textread(...
'obsPoints.out','%f %f %f %f %f %f %f %f %f %f %f %f',3,'delimiter','',...
'headerlines',3)
This works fine to read the text file, but when I replace "textread" with "textscan", leaving everything else exactly the same, I get an error message:
??? Error using ==> textscan
Too many output arguments.
It looks to me like textscan and textread follow exactly the same format, so can someone help me understand why this code works with textread but not with textscan? I'm trying to update this code and, as the documentation for textread suggests, use textscan instead of textread.
dpb
Jun 29, 2012, 4:55:43 PM6/29/12
to
On 6/29/2012 3:09 PM, Steven wrote:
...
> It looks to me like textscan and textread follow exactly the same
> format, so can someone help me understand why this code works with
> textread but not with textscan? I'm trying to update this code and, as
> the documentation for textread suggests, use textscan instead of textread.
The documentation also notes that textscan() returns a cell array of the
dimension of the number of conversion specifiers whereas textread()
returns a separate variable/array for each format field.
So, not only will you have to change to return the values in a cell
you'll then have to either recode to use the cell contents or convert
the cell contents to the existing variables to make the conversion.
What a forced waste of time for no real gain... :(
Why TMW is choosing to actually remove textread() is beyond my ken; at
least w/o replacing it w/ something that is similarly convenient when
one wishes to have individual variables. It's possible to convert from
the cell array to variables of course but it's just another step that
one has choice in using at present. Not to mention the breaking of old
code is just a bad thing to happen unless it is truly mandatory and
there seems no reason other than convenience that it should be that
necessary to remove textread().
I don't see anything wrong w/ introducing textscan(), certainly;
textread() has some warts that textscan improves upon but "the only way
is my way" as far as returning the cell is a club, certainly.
Just my $0.02333, imo, ymmv, etc., etc, etc., ...
--
...
> It looks to me like textscan and textread follow exactly the same
> format, so can someone help me understand why this code works with
> textread but not with textscan? I'm trying to update this code and, as
> the documentation for textread suggests, use textscan instead of textread.
dimension of the number of conversion specifiers whereas textread()
returns a separate variable/array for each format field.
So, not only will you have to change to return the values in a cell
you'll then have to either recode to use the cell contents or convert
the cell contents to the existing variables to make the conversion.
What a forced waste of time for no real gain... :(
Why TMW is choosing to actually remove textread() is beyond my ken; at
least w/o replacing it w/ something that is similarly convenient when
one wishes to have individual variables. It's possible to convert from
the cell array to variables of course but it's just another step that
one has choice in using at present. Not to mention the breaking of old
code is just a bad thing to happen unless it is truly mandatory and
there seems no reason other than convenience that it should be that
necessary to remove textread().
I don't see anything wrong w/ introducing textscan(), certainly;
textread() has some warts that textscan improves upon but "the only way
is my way" as far as returning the cell is a club, certainly.
Just my $0.02333, imo, ymmv, etc., etc, etc., ...
--
Jan Simon
Jun 30, 2012, 4:34:23 PM6/30/12
to
Dear dpb,
TEXTREAD calls as STRREAD the mex function dataread.c, which has been delivered with older Matlab versions. As far as I understand the license conditions, you are allowed to use it even in newer Matlab versions, if you own the old one.
Because I have to work with a bunch on different Matlab versions, I include a specific folder for each version dynamically in the initialization. This folder contains patched or missing functions, e.g. for Matlab 6.5:
Forward compatibility: ancestor, cast, commandwindow, typecast
Improved versions: filesep, ind2rgb, iscellstr, isfield, ispc, isunix, now, path, path2rc, pathsep, strcat, strvcat, tempdir, uigetfiles, waitbar.
While I did not use STRMATCH due to its slow speed, I will not miss it. But the changes of the set functions in the future will be really bad and require a lot of code reviews.
Because I'm not convinced that TEXTSCAN works exactly as DATAREAD, I assume that a conversion of the outputs to a cell is not enough. Therefore I will add the old code in the patch folder of new Matlab releases.
Btw, the removing of DATAREAD will be the next obstacle for the simple standard task to import a text file to a cell string line by line. While FILEREAD imports a string, old Matlab's did not have REGEXP('split'). And now TEXTREAD is retired - not funny.
Kind regards, Jan
TEXTREAD calls as STRREAD the mex function dataread.c, which has been delivered with older Matlab versions. As far as I understand the license conditions, you are allowed to use it even in newer Matlab versions, if you own the old one.
Because I have to work with a bunch on different Matlab versions, I include a specific folder for each version dynamically in the initialization. This folder contains patched or missing functions, e.g. for Matlab 6.5:
Forward compatibility: ancestor, cast, commandwindow, typecast
Improved versions: filesep, ind2rgb, iscellstr, isfield, ispc, isunix, now, path, path2rc, pathsep, strcat, strvcat, tempdir, uigetfiles, waitbar.
While I did not use STRMATCH due to its slow speed, I will not miss it. But the changes of the set functions in the future will be really bad and require a lot of code reviews.
Because I'm not convinced that TEXTSCAN works exactly as DATAREAD, I assume that a conversion of the outputs to a cell is not enough. Therefore I will add the old code in the patch folder of new Matlab releases.
Btw, the removing of DATAREAD will be the next obstacle for the simple standard task to import a text file to a cell string line by line. While FILEREAD imports a string, old Matlab's did not have REGEXP('split'). And now TEXTREAD is retired - not funny.
Kind regards, Jan
0 new messages