floor(0.2835*10000) = 2834 WHY???

 floor(0.2835*10000) = 2834 WHY???

[KL]

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

[Stephen23]

"WHY???"

Why do you get a correct output value when calculating with floating point values???

That output values is perfectly correct within the accumulated floating-point error of the double values that you are using.

[Jan]

 Why???

Because the Matlab is a deterministic system, you can examine the effect by your own. If floor(0.2835*10000) replies 2834, the value of 0.2835*10000 must be smaller than 2835. Check this:

0.2835 * 10000 - 2835

You will find out, that the actual question does not concern floor(), but either the manually defined "0.2835" or the multiplication by 10000. The solution is given below: 0.2835 cannot be represented in binary form with limited precision exactly.

Welcome to the world of numerics!

Answer 1

[Birdman]

Because actually, 0.2835*10000 is never exactly 2835, it is 2834.9.... This happens due to the usage of IEEE 754 double precision standard. Since floor means rounding toward negative infinity, the result is 2834.

Edit: answer is edited after Guillaume's comment.

[Guillaume]

This happens due to the precision error of MATLAB

No, this is not specific to matlab. It is specific to the way numbers are stored on a computer, using IEEE 754 double precision. You would have the same issue in any language.

The problem is because 0.2835 cannot be stored exactly in binary (the same way that you cannot write exactly the value of 1/3 = 0.3333.... in decimal)

0.2835 is actually stored as roughly 0.28349999999999997, which of course when rounded down results in .2834

[James Tursa]

Just to complete the thread, the exact conversions are:

>> num2strexact(0.2835)
ans =
0.28349999999999997424282582869636826217174530029296875
>> num2strexact(0.2835*10000)
ans =
2.83499999999999954525264911353588104248046875e3

Answer 2

[Andreas Goser]

The best answer I am aware of is posted here.