Why is MATLAB messing up this very simple calculation.

I was trying to tutor MATLAB to one of the underclassman I tutor. I came across an error that I initially could not fix. I eventually found the error but it isn't my error. MATLAB calculated the wrong number! -2.9982*5=-14.991 not -2.9982*5=-14.991000000000001. I can avoid using this calculation in the code but I just want to know what is causing this silly error so I can avoid it again.

[Viet Ha Tran]

I have found a similar issue but I would like to raise a question:

In my program, I have to compare:

11.2/1.6x1.07 with 7.49

Matlab answered that the former is lower than the later. and:

>> 11.2/1.6*1.07 - 7.49

ans =

-8.8818e-16

However, both Windows Calculator and Excel give zero difference. Using logical comparisions (equal, greater, smaller) reveal the same results: Matlab says the former is smaller than the later. Excel says they are the same.

I would like to know why, thanks!

[Stephen23]

@Viet Ha Tran: MATLAB does the calculation following the IEEE 754 standard. You can compare this against other tools that also follow IEEE 754 and get the same answer.

Windows Calculator uses an abritrary-precision arithmetic library (see https://en.wikipedia.org/wiki/Windows_Calculator), I could not find any relevant documentation online in the short time I spent searching. Possibly it uses some decimal number format, or just a really high precision binary format for storing those values.

Windows Office Excel certainly stores numbers in memory as double (i.e. binary floating point) but as far as I am aware does not document how they use these in calculations. Excel has an option to change the calculation precision based on the display format (search for "Precision as displayed"), truncates digits beyond 15 significiant figures to 0, and its development team is known to have written their own C compiler, all of which indicate that they do some of their own magic and probably also use some arbitrary precision arithmetic library.

Summary: Windows applications do not openly document how they work. MATLAB follows an international standard for binary floating point numbers.

[Viet Ha Tran]

Thank you for your quick and clear answer. I have that problem when running my script which will decide what to do depending on the comparision above. My idea now is to set, say, 10e-12 difference as zero. I see some good discussions on google search, will figure it out. Thanks again.

Answer 1

[Stephen23]

"MATLAB calculated the wrong number!"

Nope, MATLAB calculated the right number.

The reason is simply that the value -2.9982 cannot be represented exactly using binary floating point numbers, so any calculation involving that number will inevitably accumulate some floating point error.

In exactly the same way that you cannot write 1/3 exactly using a finite decimal fraction, it is impossible to store -2.9982 exactly using a finite binary floating point number. So although you might think that you have -2.9982, in fact the real values stored in computer memory is slightly different from this. And so when you perform some calculation on it, the calculation collects this floating point error, so that the final total is not going to be exactly equal to -14.991 (unless your calculation involves only powers of two).

What you see printed in the command window is the closest representation to 5 or 16 significant digits, depending on your current format setting. To see the "real" value download James Tursa's FEX submission:

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

Use James Tursa's num2strexact and you will see that that number does not really have the exact value -2.9982. All you are looking at is a representation of those floating point numbers displayed in the command window, to the precision defined by your format setting. Just because you see -2.9982 displayed in the command window tells you nothing about the real floating point number's value.

Note that you can change how the value is displayed by changing the format.

You need to learn about the limits of floating point numbers. 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

[Garrett Thomas]

Do you know why 2.9982 can't be represented in binary floating point?

[Stephen23]

"Do you know why 2.9982 can't be represented in binary floating point?"

Try writing 0.1 (base 10) exactly as a base 2 number. Then consider what that means for 2.9982.

[John D'Errico]

For exactly the same reason why 1/7 or 1/3 cannot be represented exactly as a decimal number.

1/3 = 0.333333333333333333333333333333333333333...

In MATLAB of course, the numbers that are stored are

sprintf('%0.55f',1/3)
ans =
    '0.3333333333333333148296162562473909929394721984863281250'

sprintf('%0.55f',1/7)
ans =
    '0.1428571428571428492126926812488818541169166564941406250'

Note that both of them are correct only to roughly 16 decimal digits, because they are represented in BINARY form, using a 52 bit binary mantissa (13 hexadecimal digits). Nothing matters, because you cannot store an infinite number of digits for either form.

Why cannot you do so? Well, do you have an infinite amount of memory?

So the closest binary approximation to the decimal number -2.9982 is (when written in decimal form)

sprintf('%0.55f',-2.9982)
ans =
  '-2.9982000000000001982414232770679518580436706542968750000'

Is this only a MATLAB issue? No. Most computational languages use the same floating point arithmetic storage for double precision. In fact, that is an IEEE standard form. So if you were using fortran, etc., the same things happen.

[Garrett Thomas]

Learn something new every day

[Walter Roberson]

IEEE 754 also defines a decimal floating point format, but the only systems I have heard of that implement it in hardware are some IBM Z9 systems.

Answer 2

[Micha E]

I have some problems with "wrong" calculations in Matlab too. I like to use some calculations to create idices, pretty simple and I always get positive integer by calculating it with hand.

example in Matlab:

>> 203/200*1000

ans =

1.0150e+03

by using it as index brings an error

>> 203/200*1000-203*1000/200

ans =

-1.1369e-13

shows why.

h=(1:1:1000)';
for i=1:1000
    h(i)=h(i)/200*200-h(i)*200/200;
end

The code shows were I have problems: i=7,14,28,29....

Is it a problem of my PC or Matlab ?... very strange. An answer would be great!

Thanks, Michael

[John D'Errico]

Please don't answer a question with another question. Worse, had you bothered to read the answers to the question you attached this too, you would learn something about floating point numbers.

What is 203/200? Is it an integer? Is it exactly representable as a floating point number, using a binary storage form? (Hint: no. Read the answer.) While you might think that 203/200 is 1.015, that is not what was computed.

sprintf('%0.55f',203/200)
ans =
    '1.0149999999999999023003738329862244427204132080078125000'

The number 1.015 cannot be stored exactly as a number using binary. READ THE ABOVE ANSWER. So, instead, the intermediate result is created as the mess above, an approximation to 1.015, but not in fact 1.015. In binary form, we would see the expansion of 1.015 as the infinite binary number

1.0000001111010111000010100011110101110000101000111101...

This is a repeating, non-terminating binary number, with a repeating part that appears to be: "11110101110000101000".

Then when you multiply it by 1000, is there any reason to expect the result to be an exact integer? Again, no, because MATLAB could not represent the previous computation exactly. Some information was lost in the intermediate computation. And information, once lost, is not easily recovered, often not at all.

sprintf('%0.55f',203/200*1000)
ans =
    '1014.9999999999998863131622783839702606201171875000000000000'

If it is not an integer, then it is not a valid index.

Why is there a difference when you do the operation in a different order? Thus, what is this intermediate result?

203*1000

Is that an integer? Yes. Is it less than 2^53? Yes. Is it evenly divisible by 200, still as an integer? Again, clearly yes. So MATLAB has no problem with the computation 203*1000/200. The result in that order will in fact be a positive integer, and thus potentially a valid index.

Remember that intermediate results are computed. The order in which you perform a computation DOES matter. Computer programming is NOT mathematics, only an approximation thereof. While it is often a good approximation, it is only an APPROXIMATION. And you need to understand when it is only approximate, because for SOME computations you are able to work with integers without approximation. All of this means that while you assume the commutative law should apply on computations like this, it need not in fact apply exactly.

So read the answer you apparently ignored. And when you have a question, don't hijack another question with a non-answer. Post a question.