Simple question: How to setup Matlab to calculate more precisely?

Hello,

please check the following example:

A=400;
B=220;
C=1.5;

D=(B/A)*C;
E=(B*C)/A;

F=D-E     %%%%=1.110223024625157e-16

In my opinion F must be zero?

Has anyone an explanation for this?

Thanks

[Stephen23]

"Has anyone an explanation for this?"

Because that is how floating-point arithmetic works. Small differences in the floating-point values means that you should not expect an output equivalent to some mathematical operation/s. Floating-point numbers have been explained a thousand times on this forum:

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/69-why-does-1-2-3-1-3-not-equal-zero#answer_271

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

https://www.mathworks.com/matlabcentral/answers/41536-why-is-2-24-10-22-4-not-equal-to-0

https://www.mathworks.com/matlabcentral/answers/20830-1-0010-does-not-equal-1-0010

etc, etc, etc

Answer 1

[Walter Roberson]

If you have the symbolic toolbox:

 A = sym(400);
 B = sym(220);
 C = sym(1.5);

 D = (B/A)*C;
 E = (B*C)/A;

 F = D-E

However, if you use this, you need to be aware of how sym converts floating point numbers. Read about the conversion flags at https://www.mathworks.com/help/symbolic/sym.html#input_argument_d0e141952 and read the examples at https://www.mathworks.com/help/symbolic/sym.html#bu1rs8g-1

And remember that the problem occurs in any finite number base. For example in 3 digit decimal,

v = 1/3
1 * v -> 0.333
2 * v -> 0.666
3 * v -> 0.999
1 - 3 * v -> 0.001

Calculations in any finite representation are not the same as algebraic calculations on rationals: order matters.

Answer 2

[David Goodmanson]

Hi Manuela, you have just discovered one of the features of floating point arithmetic. Matlab uses 64 memory bits for a floating point number, which corresponds to about 15 decimal digits worth of precision. When you multiply and divide quantities in different orders, there can be variations in what happens to the last bit. So you can get perfectly normal disagreement, on the order of 1e-16, in the answers.

With the symbolic toolbox it is possible to obtain precision to many, many more digits but that is much slower and mostly not necessary, once you know what floating point numbers are up to.

Matlab can represent integers exactly in the range of approximately +-9e15

[Manuela Gräfe]

Hello David, thanks for your answer. Is there any possibility to avoid this disagreements?

[David Goodmanson]

the most common situation is when you calculate two numbers x and y that some of the time 'should' be equal, and want to do the following:

if x==y
  (do something)
else
  (do something else)
end

If x and y differ by 1e-16 or some such, then the first part of the if statement mysteriously never happens. You can guard against that in various ways. If you know that x and y are supposed to come out as integers you can use x = round(x) etc. first. The most common approach is to replace the first line with

if abs(x-y) < 1e-10

or whatever tolerance you think is appropriate.

Other situations are not a problem. For example

for j = 1:1000
  for k = 1:1000
    if j==k
      (do something)
    end
  end
end

This always works since you are creating integers and comparing them.

[Walter Roberson]

I like to point out that if you calculate the same expression in two different ways, then the result might be different. Even ((A+B)+C) compared to (A+(B+C)) can give you different results.

Therefore the only time it is safe to compare floating point numbers for equality is if they are extracted from the same source. For example it is safe to test

A == min(A)

because the min(A) will be a bitwise-identical copy of some element of A