Syntax Question, Why does this equal zero?

Explain why 1 - 7*(8/7 - 1) is not equal to zero when programmed (as shown) into Matlab.

Hello all! I know this is true, but for the life of me I cannot describe why it is true. Is it possible anyone could explain why this is? I know it is simple, but I am new to MatLab and don't know some of the concepts.

Thanks in advance!

[KALYAN ACHARJYA]

Explain why 1 - 7*(8/7 - 1) is not equal to zero?

 8/7=1428571428557........

The issue with how computer represents the floating points numbers, is this 8/7=1.142857143 (Calculator) exactly? Please refer the below links and there are so many related threads of the question, please do Google.

Floating-Point Numbers

https://in.mathworks.com/matlabcentral/answers/387389-matlab-floating-point-precision

Answer 1

[Paul Hoffrichter]

Good question. :)

>>  1 - 7*( sym(8/7) - 1 )
ans =
0 % you are right; the answer is 0

For double numbers, look at the format command and its arguments.

Notice the roundoffs for the well-known cases. What is printed with format long does not show the least significant bits (LSB). When an answer is subtracted, from the expression, then you can get a sense of the LSB.

>> format long % fixed-decimal format with 15 digits after the decimal point for double values
>> 1/3
ans =
   0.333333333333333
>> 0.333333333333333 - 1/3
ans =
    -3.330669073875470e-16
>> 2/3
ans =
   0.666666666666667
>> 0.666666666666667 - 2/3
ans =
     3.330669073875470e-16

Here is my ad hoc, non-formal explanation. Look at some formating within Matlab:

>> format short
>> 7*(8/7 - 1)
ans =
    1.0000
>> format long
>> 7*(8/7 - 1)
ans =
   1.000000000000000
>> format longe
>> 7*(8/7 - 1)
ans =
     9.999999999999996e-01
>> 1 - 9.999999999999996e-01
ans =
     4.440892098500626e-16

Does this give you an idea of the hidden LSB's with format long?

When you subtract 1 from the above expression, then the hidden bits get exposed. You have discovered a serious problem when working with numbers on computers. There are methods that take these small errors into consideration so that the computations do not compound into huge errors when tens of thousands of computations are performed.

[Kimberly Griggy]

Thank you so much! That walkthrough helped me understand it perfectly.

[Paul Hoffrichter]

Oftentimes, we can see the problem right away. But, in your example, we have (using format long):

N=7;
N* ((N+1)/N - 1)
ans =
   1.000000000000000

which seems like 1 - 1 should be 0.

In other values for N, it becomes a little clearer why we do not get the value 0. For example,

N=12;
N* ((N+1)/N - 1)
ans =
   0.999999999999999

Or,

N=50;
N* ((N+1)/N - 1)
ans =
   1.000000000000001

Answer 2

[Steven Lord]

What happens if you compute it by hand? Start with the expression in the parentheses since they're at the top level of the operator precedence list. Write out the results of each computation in turn. [Hint: you're only allowed to use the decimal places you actually wrote down in later computations. No writing one divided by seven as 0.142857... and using the ellipsis to indicate repeating digits.]

Once you find that you've able to reproduce the behavior of MATLAB (perhaps not getting the same value, depending on how quickly you get bored doing long division) think about where the error could have crept into your hand calculations.