Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable -Status: Feedback +Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: . Previous Comments: ------------------------------------------------------------------------ [2010-05-24 02:04:27] codeslinger at compsalot dot com Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the "precision". This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set("precision", 16); End of Problem.... End of Bug... Like Good Day Eh? ------------------------------------------------------------------------ [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. ------------------------------------------------------------------------ [2010-05-23 09:38:47] codeslinger at compsalot dot com In response to johan...@php.net above..... Let me just very politely reiterate that I originally encountered this bug on the STOCK WINDOWS BUILD from php.net, therefore to dismiss this bug because it is ubuntu specific is not a valid reason. This bug is very hard to reproduce, but none-the-less occurs far too frequently under real-world conditions. The actual values required to reproduce this bug appear to vary depending on what version of php is being tested and what os/cpu it is running on. Given the randomly variant nature of this problem, I suspect that the only way you could properly test this bug and have confidence in the outcome is if you loop through every possible floating point value and convert it to a string. You would also need to do this on multiple platforms. Of course that would probably take a few years... so perhaps code inspection and some alerts would be a better option. Testing numbers selected at random is not likely to succeed, the number space is too large and you can't account for possible biases in the random number generator -- perhaps it only returns numbers which php sees as valid. Other people have reported this bug, see for instance #49764 and also the above comments about Mandriva Devs creating a patch to fix this bug. I do not regard millions of Ubuntu users as unimportant, or irrelevant. The severity of the consequences of this bug ought to be sufficient justification for a little bit of extra effort being expended -- even if the problem had been caused by ubuntu patches which it wasn't. People who are affected by this bug may not always realize what the problem is. This bug is probably underreported by quite a bit. Also as pointed out earlier the majority of php web pages do not do very much floating point math and therefore would not encounter this bug. In the discussion above it appears that there is some obscure case for which the number conversion is off-by-one. Pajoye thinks he has a fix. The fact that this afflicts Financial Transactions -- as reported by multiple people -- makes this a gravely serious bug... so why then is it so exasperatingly difficult to get the php dev community to take this problem seriously? In case you are wondering why it took me so long to respond to Johannes, it's because I had to cool off first.... I really am trying not to be overwrought, honest, ;-) ------------------------------------------------------------------------ [2010-04-14 04:37:08] john dot smith dot 1964 at gmail dot com The folk at Mandriva saw the same problem, figured it out and submitted a patch to PHP. I'm confused, because we're certainly still seeing the problem: https://qa.mandriva.com/show_bug.cgi?id=37171 "In PHP on Mandriva 2008, some float to string conversions return "0.0:" !! In critical software, this can lead to major loss of data or inconsistant results." ------------------------------------------------------------------------ [2010-04-13 03:36:47] john dot smith dot 1964 at gmail dot com I am seeing this bug consistently on standard Windows builds such as 5.2.4 and 5.2.13. Our Server is: Windows NT 5.2 build 3790 Sample code is simple: <? echo round(1451,2); ?> On 5.2.4 it will result in "1450.:0" every time. On 5.2.4, other such *funny* values are 1701,1821,1951,2091,2101,2111,2121,2341,2351... On 5.2.13,the numbers 1700 and 1900 consistently return "colon-ized" results. This is a especially problematic, because 1700 and 1900 occur more frequently in our eCommerce app! This issue is a real problem for us. It has been touched on (but not solved) in at least Bugs 46376, 47716, 47304 and 47418. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
