## Why does 1 - 2/3 - 1/3 not equal zero?

Asked by Ned Gulley

### Ned Gulley (view profile)

on 13 Jan 2011
Accepted Answer by Matt Fig

### Matt Fig (view profile)

Try this:
>> 1 - 2/3 - 1/3
MATLAB gets the wrong answer:
5.5511e-017

James Tursa

### James Tursa (view profile)

on 14 Jul 2011
You might find this FEX submission useful:
http://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

### Products

Answer by Matt Fig

### Matt Fig (view profile)

on 20 Jan 2011

Ned! I am sure you know that the reason why (1 - 2/3 - 1/3) ~=0 is that MATLAB does its work in floating point arithmetic, not in exact arithmetic.

Ned Gulley

### Ned Gulley (view profile)

on 20 Jan 2011
Hi Matt: Yes, this is an obvious one to get the ball rolling. By the way, I changed the formatting of your answer slightly to make the link a little clearer.

Answer by Doug Hull

### Doug Hull (view profile)

on 21 Jan 2011

As is mentioned frequently in the newsgroup, some floating point numbers can not be represented exactly in binary form. So that's why you see the very small but not zero result. See EPS.
The difference is that 0:0.1:0.4 increments by a number very close to but not exactly 0.1 for the reasons mentioned below. So after a few steps it will be off whereas [0 0.1 0.2 0.3 0.4] is forcing the the numbers to their proper value, as accurately as they can be represented anyway.
a=[0 0.1 0.2 0.3 0.4];
b=[0:.1:.4];
as=sprintf('%20.18f\n',a)
as =
0.000000000000000000 % ==
0.100000000000000010 % ==
0.200000000000000010 % ==
0.299999999999999990 % ~= bs !
0.400000000000000020 % ==
bs=sprintf('%20.18f\n',b)
bs =
0.000000000000000000 % ==
0.100000000000000010 % ==
0.200000000000000010 % ==
0.300000000000000040 % ~= as !
0.400000000000000020 % ==
% -and-
format hex;
hd=[a.',b.']
hd =
0000000000000000 0000000000000000 % ==
3fb999999999999a 3fb999999999999a % ==
3fc999999999999a 3fc999999999999a % ==
3fd3333333333333 3fd3333333333334 % ~= !
3fd999999999999a 3fd999999999999a % ==
If you're trying to compare two floating-point numbers, be very careful about using == to do so. An alternate comparison method is to check if the two numbers you're comparing are "close enough" (as expressed by a tolerance) to one another:
% instead of a == b
% use:
areEssentiallyEqual = abs(a-b) < tol
% for some small value of tol relative to a and b
% perhaps defined using eps(a) and/or eps(b)
You can see this same sort of behavior outside MATLAB. Using pencil and paper (or a chalkboard, or a whiteboard, etc.) compute x = 1/3 to as many decimal places as you want. The number of decimal places must be finite, however. Now compute y = 3*x. In exact arithmetic, y would be exactly 1; however, since x is not exactly one third but is a rounded approximation to one third, y will not be exactly 1.
For a readable introduction to floating point arithmetic, look at Cleve's Corner article from 1996: Floating Points (PDF)
For more rigorous and detailed information on floating point arithmetic, read the following paper: What Every Computer Scientist Should Know About Floating Point Arithmetic.
Another resource is Technical Note 1108 on the Support section of The MathWorks website.

Amir

### Amir (view profile)

on 28 Jul 2011
that's just an example to for the case. I need a solution to work with any given system!(G/H) wherever I do a simple arithmetic with my tf's it does not zero out when its necessary.
Amir

### Amir (view profile)

on 29 Jul 2011
basically many arithmetic functions dont work for tf objects.
Amir

### Amir (view profile)

on 29 Jul 2011
I wrote my code wondering if matlab must have it!
function [am] = cancelout(a,tol) %for small gain probelm
for k=1:size(a,1)
for m=1:size(a,2)
[z,gain] =zero(a(k,m));
if ( abs(gain)<tol)
a(k,m)=0;
end
gain=NaN;
end
end
am=a;

Answer by Derek O'Connor

### Derek O'Connor (view profile)

on 29 Jul 2011

Ned,
Let me add to the confusion by asking
1. Why does en1 = (1 - 2/3) - 1/3 = 5.5511e-017 = 2^(-54) = eps/2^2?
2. Why does en2 = 1 - (2/3 + 1/3) = 0?
3. Why does Kahan's
a = 4/3; b = a-1; c = b+b+b; ek = 1-c = 2.2204e-016 = 2^(-52) = eps?
An explanation of Kahan's result is given on page 7 of:
The difficulties in defining machine precision are discussed by Nick Higham and Cleve Moler here:
Derek O'Connor