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 > On Fri, 2008-05-02 at 19:04 +0200, Pierre Joye wrote: >> On Fri, May 2, 2008 at 6:52 PM, Jonathan Bond-Caron <[EMAIL PROTECTED]> >> wrote: >> > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
