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 -- http://mail.python.org/mailman/listinfo/python-list
