Why are there variations in values when using floor function?

Hello,

This problem has been plaguing me several days now. this problem is to do with the variation in values when using floor.

Here's the code which highlights this problem.

mat = [];

index = 1;

for i = 0.15:0.05:1.5

mat(index,1) = i/0.05;

mat(index,2) = floor(i/0.05);

index = index +1;

end

here is a photo of my results.

Why aren't the values the same?

And if possible how can you get the output to show, say 3 instead of 2 while still rounding bigger values down such as 3.6 to 3.

Thanks for any answer :)

[Stephen23]

"Why aren't the values the same?"

Because binary floating point numbers have a limited precision.

Lets try a simple decimal example. Take the number one and divide it by three. Write down the answer with four significant digits (i.e. limited precision). Now multiply what you wrote down by three: is the answer one? (hint: no)

"And if possible how can you get the output to show, say 3 instead of 2 while still rounding bigger values down such as 3.6 to 3"

Don't use fractional binary floating point numbers.

Answer 1

[Voss]

0.15/0.05

ans = 3.0000

0.15/0.05 - 3

ans = -4.4409e-16

So 0.15/0.05 returns a number that's a little bit less than 3, as it turns out (so floor(0.15/0.05) returns 2).

This is due to the nature of floating-point arithmetic.

[Riccardo Scorretti]

Exactly. The point is that 0.1 is periodic in base 2, this 0.05 = 0.1 / 2 is periodic as well. See https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/

Answer 2

[John D'Errico]

Do you understand that it is impossible to represent most fractinos as floating point numbers, and do so exactly? That is, is the fraction 2/3 EXACTLY represented by a finite number of decimal digits? How about 1/3?

Now, consider that floating point numbers are rerpesented in BINARY, using 52 binary bits for the mantissa. This is ectly the same thing as representing 2/3 as a decimal fraction. You can say

2/3 = 0.66667

or

2/3 = 0.66666

but neither of them will be correct.

So, how will MATLAB represent the FRACTION 15/100?

sprintf('%0.55f',0.15)

ans = '0.1499999999999999944488848768742172978818416595458984375'

So it is not 0.15. In fact, MATLAB cannot represent that number in binary form using finite number of binary bits. It uses this approximation instead:

format long g
x = sum(2.^[-3 -6 -7 -10 -11 -14 -15 -18 -19 -22 -23 -26 -27 -30 -31 -34 -35 -38 -39 -42 -43 -46 -47 -50 -51 -54 -55])

x = 
                      0.15

However, you should know the result is not EXACTLY 0.15. In fact, none of the values in that vector were exactly what you thought they were. Just good approximations.

Look carefully at the table you creatd. Do you see that some of the numbers you thought were integers, were shown as 3.000, not the number 3?

For example,

x = 0.15;
x/0.05

ans = 
                         3

floor(x/0.05)

ans = 
     2

Do you see that just because it shows the number 3, what you really have is only something really close?

sprintf('%0.55f',x/0.05)

ans = '2.9999999999999995559107901499373838305473327636718750000'

And that is the floor of that number? It is 2. NOT 3.