Short-circuit Logic

[Steven D'Aprano]

On Mon, 27 May 2013 13:11:28 -0700, Ahmed Abdulshafy wrote:

> That may be true for integers, but for floats, testing for equality is
> not always precise

Incorrect. Testing for equality is always precise, and exact. The problem 
is not the *equality test*, but that you don't always have the number 
that you think you have. The problem lies elsewhere, not equality!
Unfortunately, people who say "never test floats for equality" have 
misdiagnosed the problem, or they are giving a simple work-around which 
can be misleading to those who don't understand what is actually going on.

Any floating point libraries that support IEEE-754 semantics can 
guarantee a few things, including:

x == 0.0 if, and only if, x actually equals zero.

This was not always the case for all floating point systems prior to 
IEEE-754. In his forward to the Apple Numerics Manual, William Kahan 
describes a Capriciously Designed Computer where 1/x can give a Division 
By Zero error even though x != 0. Fortunately, if you are programming in 
Python on Intel-compatible hardware, you do not have to worry about 
nightmares like that.

Let me repeat that: in Python, you can trust that if x == 0.0 returns 
False, then x is definitely not zero.

In any case, the test that you show is not a good test. I have already 
shown that it wrongly treats many non-zero numbers which can be 
distinguished from zero as if they were zero. But worse, it also fails as 
a guard against numbers which cannot be distinguished from zero!

py> import sys
py> epsilon = sys.float_info.epsilon
py> x < epsilon  # Is x so tiny it looks like zero?
False
py> y = 1e17 + x  # x is not zero, so y should be > 1e17
py> 1/(1e17 - y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float division by zero


So as you can see, testing for "zero" by comparing to machine epsilon 
does not save you from Zero Division errors.


-- 
Steven