Unexpected result from linspace function

Why the result of this code

B1 = 0:0.1:1.8;
B2 = linspace(0,1.8,19)

B1(4)-0.3
B2(4)-0.3

is 5.5511e-17? I found a workaround, which is

B1 = 0:01:18;
B1 = B1/10;

But I am still wondering why the first code does not produce what it should?

Answer 1

[Rik]

Welcome to the wondrous world of floating point numbers. Matlab is a computer program, so it works with binary. Some values are impossible to represent in a binary expansion, so they get rounded. This can be different for each algorithm, so even if the end result can be represented, rounding errors can build up. That is the use case for the eps function: it shows you what the magnitude is of possible errors.

As a decimal example, consider this: (1/3)*3. Assuming I can only store 2 decimal digits, that would be 0.33*3=0.99, even if the correct answer doesn't need 2 decimals.

[Rostislav Teryaev]

But this issue can be overcomed by using another algorithm inside 0:0.1:1.8 notation. Why this has not been already implemented? It seems to be obvious. Just like this:

array = zeros(1,floor(1.8/0.1))
for i = 1:length(array)+1
 array(i) = (i-1)*0.1;
end

[Rostislav Teryaev]

hm, I just tried my code and it seems that algorithm inside a:step:b implemented in the same way, because I also got 5.5511e-17(

[Rik]

It isn't a problem with the minus function either, as array(4)==0.3 returns false. That is the reason why you shouldn't use equality in such cases, but abs(array(4)-0.3)<eps (or use functions that do this internally, like ismembertol and uniquetol).

[Stephen Cobeldick]

"But this issue can be overcomed by using another algorithm inside 0:0.1:1.8 notation. Why this has not been already implemented? It seems to be obvious. Just like this:"

No, that does not overcome the "issue" at all. The first thing is to understand that 0.1 cannot be stored exactly by binary floating point numbers, in exactly the same way that you cannot write 1/3 as a finite decimal. Also understand that different calculations can produce different floating point error.

Your "algorithm" does not solve anything, because the floating point error will always be there. And no matter what way you calculate those values, someone will compare those values with the results of a different calculation that results in a different floating point error and so the comparison will fail in exactly the same way. You have not solved anything.

The actual solution is to compare the absolute value against a tolerance:

abs(A-B)<tol

In any case, this has all been discussed in lots of detail before. Start by reading these:

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

[Rostislav Teryaev]

Thank you!