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).

[Stephen23]

"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!

[VIGNESH BALAJI]

Is there any work around to deal with floating point arithmetic problems in matlab ?

[Rik]

@VIGNESH BALAJI what did you have in mind? This is a fundametal side effect of floats. So only not using a float can avoid this problem.

[Stephen23]

"Is there any work around to deal with floating point arithmetic problems in matlab ?"

The problem is not "in MATLAB", it is simply how your computer stores floating point numbers. MATLAB runs on your computer: if there was a simple "work around" then everyone would use it, not just MATLAB.

You can certainly use symbolic or high precision classes, but then your code will be much slower.

[Dyuman Joshi]

"Is there any workaround to deal with floating point arithmetic problems?"

@VIGNESH BALAJI - There, I fixed the question for you.

Certainly, one option is to use a computer that runs on a decimal system. There might be a lot of complications, though.

As long as you use computers that use the binary system, you will encounter floating point errors.

Rik and Stephen have already provided suggestions as to what you can do as workarounds, I'll just reiterate them -

You can avoid using floats.

Well, what to use then? Symbolic numbers or high precision classes, which work at the cost of the code performance.