Thanks for all the feedback, My questions and the title of this thread should probably be rephrased, I understand now that changing the "float comparison" would be a "fatal flaw in the language" and apologies for ever mentioning it.
Before I ask any other questions, I would like to understand how float->string conversion works: php -dprecision=100 -r 'echo 0.3,"\n";' 0.299999999999999988897769753748434595763683319091796875 php -dprecision=8 -r 'echo 0.3,"\n";' 0.3 php -dprecision=8 -r 'echo 0.3*0.075,"\n";' 0.0225 I have checked out PHP from CVS and I'm looking at zend_operators.c : convert_to_double(zval *op) Is this the right place? This question stems from a scenario I see often, some programmers using PHP to do accounting and the result is often well, let's say things are not what they would expect (not all PHP programmers have a CS degree). Bcmath does solve the problem, but maybe there's room for improving how PHP could natively compare and manipulate decimals with limited precision (i.e. currency, taxes etc..). The fact that frameworks need workarounds (i.e. Zend_Locale_Math) is an indicator that it's an important use case for the community... If someone could point me to the float->string code, I'd really appreciate j -----Original Message----- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: May 4, 2008 7:06 AM To: Todd Ruth Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Float comparison 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
