Conversion of numeric to string in MATLAB -

suppose want conver number 0.011124325465476454 string in matlab.

if hit

mat2str(0.011124325465476454,100)

i 0.011124325465476453 differs in last digit.

if hit num2str(0.011124325465476454,'%5.25f')

i 0.0111243254654764530000000

which padded undesirable zeros , differs in last digit (3 should 4).

i need way convert numerics random number of decimals exact string matches (no zeros padded, no final digit modification).

is there such way?

edit: since din't have in mind info precision amro , nrz provided, adding more additional info problem. numbers need convert come c++ program outputs them txt file , of c++ double type. [note: part inputs numbers txt file matlab not coded me , i'm not allowed modify keep numbers strings without converting them numerics. have access code's "output" numerics i'd convert]. far haven't gotten numbers more 17 decimals (note: consequently example provided above, 18 decimals, not indicative).

now, if number has 15 digits eg 0.280783055069002

then num2str(0.280783055069002,'%5.17f') or mat2str(0.280783055069002,17) returns

0.28078305506900197

which not exact number (see last digits).

but if hit mat2str(0.280783055069002,15) get

0.280783055069002 correct!!!

probably there million ways "code around" problem (eg create routine conversion), isn't there way using standard built-in matlab's desirable results when input number random number of decimals (but no more 17);

my hpf toolbox allows work arbitrary precision of numbers in matlab.

in matlab, try this:

>> format long g >> x = 0.280783054 x =                0.280783054 

as can see, matlab writes out digits have posed. how matlab "feel" number? store internally? see sprintf says:

>> sprintf('%.60f',x) ans = 0.280783053999999976380053112734458409249782562255859375000000 

and hpf sees, when tries extract number double:

>> hpf(x,60) ans = 0.280783053999999976380053112734458409249782562255859375000000 

the fact is, decimal numbers not representable in floating point arithmetic double. (0.5 or 0.375 exceptions rule, obvious reasons.)

however, when stored in decimal form 18 digits, see hpf did not need store number binary approximation decimal form.

x = hpf('0.280783054',[18 0]) x = 0.280783054  >> x.mantissa ans =   2 8 0 7 8 3 0 5 4 0 0 0 0 0 0 0 0 0 

what niels not appreciate decimal numbers not stored in decimal form double. example 0.1 internally?

>> sprintf('%.60f',0.1) ans = 0.100000000000000005551115123125782702118158340454101562500000 

as see, matlab not store 0.1. in fact, matlab stores 0.1 binary number, here in effect...

1/16 + 1/32 + 1/256 + 1/512 + 1/4096 + 1/8192 + 1/65536 + ... 

or if prefer

2^-4 + 2^-5 + 2^-8 + 2^-9 + 2^-12 + 2^13 + 2^-16 + ... 

to represent 0.1 exactly, take infinitely many such terms since 0.1 repeating number in binary. matlab stops @ 52 bits. 2/3 = 0.6666666666... decimal, 0.1 stored approximation double.

this why problem precision , binary form double comprises.

as final edit after chat...

the point matlab uses double represent number. take in number 15 decimal digits , able spew them out proper format setting.

>> format long g >> eps  ans =  2.22044604925031e-16 

so example...

>> x = 1.23456789012345 x =           1.23456789012345 

and see matlab has gotten right. add 1 more digit end.

>> x = 1.234567890123456 x =           1.23456789012346 

in full glory, @ x, matlab sees it:

>> sprintf('%.60f',x) ans = 1.234567890123456024298320699017494916915893554687500000000000 

so beware last digit of floating point number. matlab try round things intelligently, 15 digits on edge of safe.

is necessary use tool hpf or mp solve such problem? no, long recognize limitations of double. tools offer arbitrary precision give ability more flexible when need it. example, hpf offers use , control of guard digits down in basement area. if need them, there save digits need corruption.