Float comparison

Hi Todd,

I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
"==" doesn't exist

We are not the ones to consider that, that's a fact since the very
first floating point unit was implemented. That's a golden rule in
programming.

Cheers,

Pierre
http://blog.thepimp.net | http://www.libgd.org

Todd Ruth schrieb:

I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
"==" doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.

It could be worse, however. At least the cast to string works
as one would expect. Just imagine if those who oppose
improving "==" had their logic extended to the cast to string.
Php might to the following:

<?php
$x=.3+.4+.5;
print "$x\n";
?>

might output "1.19999999999999996447286321199499070644378662109375"

If someone filed a bug report, they could refer you to that
paper and tell you there's no bug because you're trying to get
a string from float and you never know what you might get.

Actually, depending on ini settings, that happens:

$ php -dprecision=100 -r 'echo 0.3+0.4+0.5,"\n";'
1.1999999999999999555910790149937383830547332763671875

Don't echo floats, use printf() or alike.

And you'll quickly see that the "cast to string before comparision" is a
bad idea, because:
$ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);'
bool(true)

Having display settings affect comparisions seems like a really bad idea
to me ;)

Regards,
Stefan

Hello Todd,

please read that article to get at least a minimum understanding of what
float values are. Speaking of comparisons and floating point values you
might want to consider using fixed point values. That is you decide how
many digits you want for your fractions. Another option is to use two ints
to present numbers (numerator/denominator). The third solution is to always
round (but then the float rules apply again to some extend). The forth
solution is to do BCD arithmetics which might be a bit slower even.

Maybe you should have a look into PHP's bcmath extension.

Anyway, just to get this straight. The comparison operators work indeed
perfectly for float values. They just don't lead to the results you might
expect. And that is in fact a result from their design. And that design is
used in all modern CPUs. The ways out are mentioned above and interstingly
some high end processors even support one or the other in silicon.

marcus

Friday, May 2, 2008, 7:36:33 PM, you wrote:

I'm afraid you'll find Pierre's response representative. The
php devs seem to consider the fact that a theoretically perfect
"==" doesn't exist to mean that the improvements that would
cover 99.9% of user issues with float == shouldn't be made.

It could be worse, however. At least the cast to string works
as one would expect. Just imagine if those who oppose
improving "==" had their logic extended to the cast to string.
Php might to the following:

<?php
$x=.3+.4+.5;
print "$x\n";
?>>

might output "1.19999999999999996447286321199499070644378662109375"

If someone filed a bug report, they could refer you to that
paper and tell you there's no bug because you're trying to get
a string from float and you never know what you might get.
So we can at least be glad that casts to string work as the
average person would expect. We can hope that someday the
fact that the cast to string works as expected will inspire
them believe that making "==" work as expected wouldn't be
a bad thing.

Seriously though, the biggest issue I see with improving "=="
is the implication for other features. For example, what
should the following code do?

$a[.3+.4+.5] = "hello";
print isset($a[1.2])

Should floats be allowed as array indices? I would say no because
I'd rather floats be converted to strings before being used as
array indices. That would make the above code work as the
average person would expect. Unfortunately, that would be a huge
BC break. However, perhaps the perfect shouldn't be the enemy of
the good and we shouldn't let the inability to fix floats as
array indices be a reason not to improve "==".

• Todd

Hi,

I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison

I'd like to know if there are reasons not to change the default behavior
when comparing floats.

i.e. This would seem logical to me:

            $test = 19.6*100;

            if((float)(string)$test == (double)1960)

                            echo "GOOD BEHAVIOR";



            // Implicitely convert the float to string then float (en_US

locale)

            if($test == (double)1960)

                            echo "THIS SHOULD PASS by casting

(float)(string)$test internally...";

            else

                            echo "NOT GOOD BEHAVIOR";



            // Exact comparison would still fail

            if($test !== (double)1960)

                            echo "GOOD BEHAVIOR";

Any reason why $test == (double)1960 should fail? I realized we are
comparing two floats, but couldn't php internally convert to string then
float - for the non strict (===) case

From our bug report:
"
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Thank you for your interest in PHP.
"

We use this text as automatic reply for bugs about floating points (aka bogus).

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

Best regards,
Marcus