From: us on 12 May 2010 14:16 "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 12 May 2010 14:52 "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 12 May 2010 15:09 "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 12 May 2010 15:30 "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 12 May 2010 16:39
"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 ;) |