Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396 Updated by: ras...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: I ran your simplefail.php on all 4 data files. Never saw the failure case. Then I took just the huge rawpairs.txt file (had to increase the memory_limit) and modified your program slightly to do: for($i=0;$i<100000;$i++) ConvertData($data); and ran that, which took quite a while. Still no failures. You are still the only person who has ever reported these weird ":" characters showing up, and you have yet to produce any sort of code that reproduces it for someone else. We'll keep trying, but something that happens for 1 person out of millions is suspicious. Previous Comments: ------------------------------------------------------------------------ [2010-03-26 15:28:16] codeslinger at compsalot dot com it's still not 20 lines... it never will be.... but I found one surprising thing, if I save the array to disk and read it back in I still get the same failure. so essentially the snowflake is a Psudo-RNG and that's why trying to simplify it does not work, because it has to be able to generate all of those different numbers. but once we have the set of numbers the generator becomes irrelevant. Try this program: http://www.compsalot.com/phpbug/kochsnowflake/simplefail/ weirdly, every failure is a -0.1 but there are two things that I'm concerned about. 1) It seems unlikely that the billing program was only failing on that amount, it is a pretty unusual amount. Not one I'd normally expect to see and there were a lot of failures. 2) I'm concerned about the limitations of the detection method. I am only finding bad values because they have a colon in the string. I am not currently checking for mathematical correctness. We may not be seeing the whole story, there could be a lot more bad values that just are not blatant enough to be observed. But at least this should give you the starting point that you are asking for. The program is reduced to reading a file from disk and checking each number to see if it's valid. can't get any simpler than that. Of course if the corruption is happening when the value is created, looking at them after the fact may still not help much. But when I look at these values in the eclipse zend debugger, they look normal enough despite the fact that they can't be properly converted. ------------------------------ The data files are as follows: rawpairs.txt is a 6.5meg file and contains both good and bad values, you don't need this file unless you are trying to validate the serialization. This is from a single run of the snowflake, $Nest = 3; $Depth = 5; The following were extracted from the raw data. onepair.txt contains a single failure item selectpairs.txt contains 8 failures which were from a single run of snowflake manypairs.txt contains about 40 failures which are the result of multiple runs of the snowflake using different Nest & Depth parameters. ------------------------------------------------------------------------ [2010-03-26 11:14:13] paj...@php.net Does it happen always? Can you try to make a script with only this function call with the values causing this effect? ------------------------------------------------------------------------ [2010-03-26 11:11:05] codeslinger at compsalot dot com String conversion errors There is a flag called $FloatType You can use it to select the type of conversion that is done. //this fails with string conversion error case 0: $s = (string)$f; //this fails with string conversion error case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f; //this fails with string conversion error case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f; //this WORKS, does not cause a string conversion error case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f; When I say conversion error, I mean that the result is "0.0:" not that php gives any kind of error message. ------------------------------------------------------------------------ [2010-03-26 10:23:27] codeslinger at compsalot dot com quote: Btw, it could be due to bad initialized data as well I don't understand the question/statement. The program generates all of it's data. If you look near the bottom of pov.pco.php you will see the following line: echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n"; If you set a breakpoint there in a php debugger and examine the vaules you will see that that array contains a float of 0.1 and that the string it was converted to is "0.0:" ------------------------------------------------------------------------ [2010-03-26 10:17:47] codeslinger at compsalot dot com Thank You for the response. This program executes thousands of identical loops it performs a number format conversion on each of those thousands of numbers in it's array. Out of all of those thousands of identical conversions about 4 of them will produce an invalid result. for this specific program, if I skip the array_merge (see $Nest) then the bug does not occur. Every time I make a change to the loops etc. the behavior changes, even to where the bug is not triggered. I have already simplified this program quite a bit and the result was that it now fails at a totally different array index then when I first observed the problem. The trigger is very finicky. XP is not a factor here, even though the original problem was found on XP, I am running this Snowflake program on Ubuntu Linux. converting a number to a string should never result in that string containing a non-numeric character. I can try to reduce this program further, but really and truly, it is hard to trigger this -- but once triggered it is totally consistent and repeatable. ------------------------------------------------------------------------ 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
