Numeric miscalculation on the 14th decimal place

I run a model based on casual differential equations and solved them with ode45. I calculated the slope of a solution of one of the equations with log diff(values) and calculated the mean from that. I wanted to put this mean slope in relation to other slopes I got from different calculations. Matlab does not display the exact value but seems to keep it in its working memory until the 14th decimal place(?). When I use this slope as it is to do some basic calculations, everything is fine. For example for the default slope I want to compare all my other slopes with it which is -0.026097431101009

When I do the following calculation:

deltaslope=((sloperun*100)/slopedefaultvalue)-100

Matlab seems to do a miscalculation on the 14th decimal place; one of my calculations include that I do it with the already default slope which should lead to 0 (because there is no difference) but it leads to 4.263256414560601e-14 as a difference that shouldn't be there. I actually need the basic calculation to put it into context. I guess matlab just tries to be as exact as possible and just produces this kind of error because it just can't calculate all decimal places. Does somebody has an idea how to avoid that? Is there a setting I could change to force matlab to just keep one decimal place?

Answer 1

[dpb]

MATLAB used double precision floating point for calculations which is good to roughly 15 decimal digits. Hence, when you subtract similar values, a difference within that or an extra digit of precision loss is to be expected.

You can round to whatever level of precision you need/desire that will turn such a small value to identically zero.

Such issues are just a fact of life with floating point arithmetic; they're not errors, just artifacts of finite precision and rounding and that not all values are exactly representable in binary arithmetic just as some fractions are irrational in base decimal (like 1/7, etc.).

That you get a nonzero result for two cases of the default value indicates that the two values were computed/stored by different computational paths such that they didn't round the same way. This can happen owing to one being entered as a numeric text string which is interpreted by the i/o routines while the other may have been computed. This can easily be the source of such a rounding effect as seen when subtract the two.

[Walter Roberson]

http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F