From: us on
"Kyle " <kbrig035(a)uottawa.ca> wrote in message <hseqmd$r99$1(a)fred.mathworks.com>...
> Thanks guys, I solved the problem via num2str :)

well... don't...
and - why not: just look at the enormous overhead of NUM2STR

dbtype num2str;

compared to your rather simple requirement, which you can easily cover with a call to the built-in SPRINTF...

us
From: Kyle on
"us " <us(a)neurol.unizh.ch> wrote in message <hser94$4e2$1(a)fred.mathworks.com>...
> "Kyle " <kbrig035(a)uottawa.ca> wrote in message <hseqmd$r99$1(a)fred.mathworks.com>...
> > Thanks guys, I solved the problem via num2str :)
>
> well... don't...
> and - why not: just look at the enormous overhead of NUM2STR
>
> dbtype num2str;
>
> compared to your rather simple requirement, which you can easily cover with a call to the built-in SPRINTF...
>
> us

I'll keep that in mind for the future, thank you.
From: John D'Errico on
"us " <us(a)neurol.unizh.ch> wrote in message <hser94$4e2$1(a)fred.mathworks.com>...
> "Kyle " <kbrig035(a)uottawa.ca> wrote in message <hseqmd$r99$1(a)fred.mathworks.com>...
> > Thanks guys, I solved the problem via num2str :)
>
> well... don't...
> and - why not: just look at the enormous overhead of NUM2STR
>
> dbtype num2str;
>
> compared to your rather simple requirement, which you can easily cover with a call to the built-in SPRINTF...
>
> us

While it may be less efficient, the difference on a small set of
numbers will still be small, certainly so compared to the time
to read in a number of data sets from disk.

John
From: us on
"John D'Errico" <woodchips(a)rochester.rr.com> wrote in message <hseucg$nil$1(a)fred.mathworks.com>...
> "us " <us(a)neurol.unizh.ch> wrote in message <hser94$4e2$1(a)fred.mathworks.com>...
> > "Kyle " <kbrig035(a)uottawa.ca> wrote in message <hseqmd$r99$1(a)fred.mathworks.com>...
> > > Thanks guys, I solved the problem via num2str :)
> >
> > well... don't...
> > and - why not: just look at the enormous overhead of NUM2STR
> >
> > dbtype num2str;
> >
> > compared to your rather simple requirement, which you can easily cover with a call to the built-in SPRINTF...
> >
> > us
>
> While it may be less efficient, the difference on a small set of
> numbers will still be small, certainly so compared to the time
> to read in a number of data sets from disk.
>
> John

sure, but sometimes every tic counts in life...

% data obtained from a wintel sys: ic2/2*2.6gzh/2gb/winxp.sp3.32/r2010a.32

v=rand(1000,3);
tic;
for i=1:1000;
sprintf('%10.5e\n',v);
end;
toc
tic;
for i=1:1000;
num2str(v,'%10.5e\n');
end;
toc
%{
Elapsed time is 4.073945 seconds. % <- SPRINTF
Elapsed time is 12.831014 seconds. % <- NUM2STR
%}

us
From: Kyle on
"us " <us(a)neurol.unizh.ch> wrote in message <hsevkf$gcj$1(a)fred.mathworks.com>...
> "John D'Errico" <woodchips(a)rochester.rr.com> wrote in message <hseucg$nil$1(a)fred.mathworks.com>...
> > "us " <us(a)neurol.unizh.ch> wrote in message <hser94$4e2$1(a)fred.mathworks.com>...
> > > "Kyle " <kbrig035(a)uottawa.ca> wrote in message <hseqmd$r99$1(a)fred.mathworks.com>...
> > > > Thanks guys, I solved the problem via num2str :)
> > >
> > > well... don't...
> > > and - why not: just look at the enormous overhead of NUM2STR
> > >
> > > dbtype num2str;
> > >
> > > compared to your rather simple requirement, which you can easily cover with a call to the built-in SPRINTF...
> > >
> > > us
> >
> > While it may be less efficient, the difference on a small set of
> > numbers will still be small, certainly so compared to the time
> > to read in a number of data sets from disk.
> >
> > John
>
> sure, but sometimes every tic counts in life...
>
> % data obtained from a wintel sys: ic2/2*2.6gzh/2gb/winxp.sp3.32/r2010a.32
>
> v=rand(1000,3);
> tic;
> for i=1:1000;
> sprintf('%10.5e\n',v);
> end;
> toc
> tic;
> for i=1:1000;
> num2str(v,'%10.5e\n');
> end;
> toc
> %{
> Elapsed time is 4.073945 seconds. % <- SPRINTF
> Elapsed time is 12.831014 seconds. % <- NUM2STR
> %}
>
> us

For the small data sets I am working with, the difference between them is on the order of a few seconds, which is hardly anything to worry about. For larger data sets you are right, using C style string handling is much better. No need to argue about it, it comes down to a matter of convenience, and I already wrote the script with num2str ;)