Matlab basic arithmetics error | Sum rounding

Hello Everyone,

I have notice a curious "property" of Matlab. It is not able to compute a sum with finite decimal (two decimals). On one hand, when I compute the follwoing some in format long I get this:

>> format long
>> 2.15+1.4+0.3+1.85
ans =
   5.699999999999999

Which differs from the true value:

>> 5.7 - (2.15+1.4+0.3+1.85)
ans =
     8.881784197001252e-16
>> eps
ans =
     2.220446049250313e-16
     

(By the way, how is possible the diference between the true value and the Matlab computation is more than the "epsilon" of the machine?)

In the other hand, if we do the same in format short we get:

>> format short
>> 2.15+1.4+0.3+1.85
ans =
    5.7000
>> 5.7-ans
ans =
   8.8818e-16

So it show "5.7000" but it really saves 5.6999... with some high precision.

Why is this? And why the sum with only two decimals has a rounding error? I suspect is because how Matlab computes the sum in binary numbers. In some step of the computation a periodic binary number must appear and spoils the sum.

[Stephen23]

No surprises here. Your questions can be answered by reading about binary floating point numbers:

https://www.mathworks.com/matlabcentral/answers/57444-faq-why-is-0-3-0-2-0-1-not-equal-to-zero

https://www.mathworks.com/matlabcentral/answers/316889-why-two-equal-numbers-are-not-equal

http://www.mathworks.com/matlabcentral/answers/102419-how-do-i-determine-if-the-error-in-my-answer-is-the-result-of-round-off-error-or-a-bug

http://www.mathworks.com/matlabcentral/answers/140656-about-numerical-difficulty-of-equality-comparison-operation-between-two-double-real-numbers-in-matlab

This is worth reading as well:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

http://faculty.tarleton.edu/agapie/documents/cs_343_arch/papers/1991_Goldberg_FloatingPoint.pdf

Answer 1

[Jan]

Welcome to the world of numerical maths. As Stephen has explained already, calculations with limited precision are expected to have rounding errors. Most fractional values cannot be represented accurately as binary numbers such that even 0.1+0.1+0.1 ~= 0.3 .

Activating a rounding in the output by format short rounds the outputs.

how is possible the diference between the true value and the Matlab computation is more than the "epsilon" of the machine?

Epsilon is the smallest number which satisfies 1+eps ~= 1 with limited precision. This means, that 2+eps does equal 2. The value of the truncation error depends on the magnitude of the number. Therfore the command eps() accepts the value as input argument:

eps
eps(1)   % 1 is the default value
eps(2)

In consequence building the sum of 2.15, 1.4, 0.3, 1.85 can accumulate the eps values for the different operations. eps(5.7) = 8.8818e-16, so this is the expected error.

The effects of computations with limited precision are well known and not "curious". They are explained in the first two lessons of numerical maths and on the first pages of each book about this topic. Especially the cancellation is important, which occurs if you subtract two almost equal numbers, e.g. in the quotient of differences:

diff_F = (F(x + h) - F(x)) / h

If h is chosen too small, the difference in the counter is dominated by rounding errors and dividing by a tiny value let the error explode.