Question

I try to create unit test cases to check my table values are correct or wrong.

This is my codes

echo $a = 2/9;
echo "<br>".$b=0.22222222222222;

echo "<br>".gettype($a);
echo "<br>".gettype($b);
if($a==$b){
    echo "<br>". "equal";
}else echo "<br>". "Not equal";


if((string)$a==(string)$b){
    echo "<br>". "equal";
}else echo "<br>". "Not equal";

Why my first if condition not working? I can’t find the reason. Please help me.

Answer 1

The test violates a cardinal rule of floating point programming: never do equality comparisons.

There are a number of problems that stem from the fact that floating point fractions have a large yet finite number of bits. These problems are commonly called “rounding errors” although for the most part they are not errors but format limitations.

For example, because of the way we write numbers when programming … as decimal strings … most of the numbers we can write do not have a corresponding representation in the floating point format if they have a decimal fraction. The fractional part repeats in base two.

This largely rules out comparing floating point numbers exactly, except, ironically, between integral values. You need to implement a fuzzy comparison such as abs(a - b) < epsilon.

And actually, your 2/9 is a jackpot case that doesn’t have a finite representation as either a decimal string or a binary string!¹

To compare 2/9 successfully for equality with a constant places more requirements for perfection on the program, the interpreter, and library than can be counted on.

For example, you would have to type more 2s than you need and the interpreter would have to round the constant’s low order bits with knowledge of more precision than the format has. The machine actually has a few bits of extra knowledge when performing the operation but the interpreter may not when converting the constant. Also, the runtime rounding is subject to various options and a language like PHP may not even specify exactly how unrepresentable constants are rounded from source code to internal form.

And actually it’s worse than that, because the individual 0.2 / 10ⁿ components in the decimal string also do not have exact binary equivalents. So, it’s quite likely that a really perfect and faithful conversion of 0.22222222222222 does not actually equal a best-effort representation of the actual 2/9. You cannot express as a finite decimal string the exact base-2 fraction that most closely represents 2/9 in any specific (finite) number of bits.

(We must have somewhere a standard answer about not doing equality comparisons with floating point numbers.)

---

_{1.
Every machine fraction is a rational number of the form x/2ⁿ. Now, the constants are decimal and every decimal constant is a rational number of the form x/(2ⁿ * 5^m). The 5^m numbers are odd, so there isn’t a 2ⁿ factor for any of them. Only when m == 0 is there a finite representation in both the binary and decimal expansion of the fraction. For example, 1.25 is exact because it’s 5/(2²*5⁰) but 0.1 is not because it’s 1/(2⁰*5¹). And for the rational number 2/9, there is neither a 2ⁿ or a 5^m factor.}