Question about machine epsilon

Hello! So I tried understanding machine epsilon, and I've properly understood that it's the smallest distance between the number 1 and the next, larger floating-point number. That said, I tried a few things_

1 + eps   > 1 % Returns true
1 + eps/2 > 1 % Returns false

This is all logical to me, however, this I do not get:

1 + eps/1.5 > 1 % Returns true

This suggests that 1 + eps/1.5 (which is smaller than 1 + eps) can be stored as a number without being rounded to 1, which contradicts the definition of epsilon. So naturally, I thought that eps/1.5 was rounded somehow, before being added to 1, but the only explanation that can justify it is if eps/1.5 is somehow rounded to eps. However, since both 1 + eps/1.99 > 1 and 1 + eps/1.01 > 1, I just don't see how that makes any sense. It seems that 1 + eps/2 is the smallest number N which yields that 1 + N = 1. Why not a larger number? I know that I'm missing something, and I think it's related to the computer using binary to compute.

Thanks in advance!

Answer 1

[James Tursa]

The short answer is that the result is rounded. How this rounding takes place is going to depend on the rounding modes available and the floating point scheme being used for your hardware/OS setup. For MATLAB this will be IEEE double precision, and the result is as if "infinite precision" is used for the rounding. See this link under "Rounding modes":

https://en.wikipedia.org/wiki/Floating_point

So in your particular operation of 1+eps/2, if the Banker's Rounding method is used ("ties to even"), the result last bit would be 0 since that is the "even" rounded result for this exact tie case. Hence the 1+eps/2 would round down to 1 and you get 1+eps/2>1 being false.

For all of the other cases you mention with 1+eps/1.5, 1+eps/1.99, 1+eps/1.01 etc these are not exact tie cases since the eps/whatever part is greater than eps/2, so the "round to nearest" result is taken for these which results in 1+eps. Even if the eps/whatever part is only greater than eps/2 in the least significant bit, the result of 1+eps/whatever will still round up to 1+eps. E.g.,

>> e2 = eps/2
e2 =
   1.1102e-16
>> num2hex(e2)
ans =
3ca0000000000000   <-- exactly eps/2
>> e21 = e2 + eps(e2)
e21 =
   1.1102e-16
>> num2hex(e21)
ans =
3ca0000000000001   <-- only 1 least significant bit greater than eps/2
>> 1+e2>1
ans =
     0    <-- using exactly eps/2 rounds down to "even" exact 1
>> 1+e2 == 1
ans =
     1
>> 1+e21>1
ans =
     1    <-- using slightly greater than eps/2 rounds to "nearest" 1+eps
>> 1+e21 == 1 + eps
ans =
     1

You can see the rounding "ties to even" pattern more clearly with this vectorized example, where the resulting least significant bit for these contrived exact tie cases is always even 0:

>> num2hex((1+(0:8)'*eps)+eps/2)
ans =
3ff0000000000000
3ff0000000000002
3ff0000000000002
3ff0000000000004
3ff0000000000004
3ff0000000000006
3ff0000000000006
3ff0000000000008
3ff0000000000008

Answer 2

[Walter Roberson]

 (1 + eps/1.5) - (1 + eps)

gives 0. So 1 + eps/1.5 is being rounded to 1 + eps.

Computations are carried out with at least 1 guard bit and then rounded.