Take the 2-minute tour ×

I think I found a bug in Matlab. My only explanation is, that matlab calculates internally with other values than the ones which are displayed:

K>> calc(1,11)

ans =


K>> floor(ans)

ans =


Displayed code is an output from the Matlab console. calc(x,y) is just an array of double values.

share|improve this question
how was the value calc(1,11) computed/loaded/generated? –  tmpearce Sep 26 '12 at 21:46
found this. it's for python but it may give an idea.. –  gokcehan Sep 26 '12 at 21:50
I suspect if you took calc(1,11) out to its full precision, you would find that it is 3.9999999999999999999999999917825619641 or something of the sort. Floating point math is inexact. Please read any of the other 12986125701 questions on SO showing other errors stemming from FP inaccuracies... –  im so confused Sep 26 '12 at 21:57
No. it is not a bug, so you are apparently not as familiar as you think with floating point. –  user85109 Sep 26 '12 at 22:50
like my old professor of programming 101 said: "Don't you ever dare claiming that C/Matlab/whatheverlanguage is bugged! 99.999% of the cases is your fault / you don't know enough!" –  Luca Cavazzana Sep 26 '12 at 23:36
show 3 more comments

2 Answers

up vote 7 down vote accepted

MATLAB uses the standard IEEE floating point form to store a double.

See that if we subtract off a tiny amount from 4, MATLAB still diplays 4 as the result.

>> format long g
>> 4 - eps(2)
ans =

In fact, MATLAB stores the number in a binary form. We can see the decimal version of that number as:

>> sprintf('%.55f',4-eps(2))
ans =

Clearly MATLAB should not display that entire mess of digits, but by rounding the result to 15 digits, we get 4 for the display.

Clearly, the value in calc(1,11) is such a number, represented internally as less than 4 by just a hair too little that it rounds to 4 on display, but it is NOT exactly 4.

NEVER trust the least significant displayed digit of a result in floating point arithmetic.


You seem to think that 3.999999999999999 in MATLAB should be less than 4. Logically, this makes sense. But what happens when you supply that number? AH yes, the granularity of a floating point double is larger than that. MATLAB cannot represent it as a number less than 4. It rounds that number UP to EXACTLY 4 internally.

>> sprintf('%.55f',3.9999999999999999)
ans =
share|improve this answer
add comment

What you got was a value really close to but lower than 4, and even with format long Matlab has to round to the 15th digit to display the number. Try this:

format long
asd = 3.9999999999999997 %first not-9 @16th digit

gives 4.000000000000000. So if I didn't already know the real value of asd I should suspect it is at least 4, but

asd >= 4

gives 0, and so floor(asd) returns 3.

So is a matter of how Matlab rounds the displayed output, the true value stored in the variable is less than 4.


if you go further with the digits, like 18x9:

>> asd = 3.999999999999999999
asd = 
>> asd == 4
ans =

asd becomes exactly 4! (notice is no more 4.000000000000000) But that's another story, is no more about rounding the number to have a prettier output, but about how the floating point arithmetic works... Real numbers can be represented up to a certain relative precision: in this case the number you gave is so close to 4 that it becomes 4 itself. Take a look to the Python link posted in the comment by @gokcehan, or here.

share|improve this answer
My Problem is, that in this case floor() still returns the expected value. E.g. B = 3.9999999999999999 --> B = 4 --> floor(B) = 4. This doesn't match floor(4.00000......) = 3 –  Bernhard Schlegel Sep 26 '12 at 23:01
that's because you added even more digits, now is about floating point representation. I updated the answer. –  Luca Cavazzana Sep 26 '12 at 23:23
@Batsu Did you mean to write "floor(asd) returns 3"? (nice answer though, +1) –  Colin T Bowers Sep 27 '12 at 0:29
you're right, fixed –  Luca Cavazzana Sep 27 '12 at 7:57
add comment

Your Answer


