#43053 [Com]: Scientific notation
ID: 43053 Comment by: int-e at gmx dot de Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: In the hope that this speeds up fixing the bug, here's a version of above patch that applies cleanly against php 5.2.6. The formatting of the code in question is different in the subversion trunk, but it's the same otherwise. At least that's how it was two months ago. http://int-e.home.tlink.de/php/php-5.2.6-printf.patch (use patch -p1 to apply) Previous Comments: [2008-06-30 14:38:33] admin at shadowops dot net This bug is not limited to the Round() and related commands. I have been hit by it and it has caused many issues with MYSQL and values entered into the DB. 120 in debug mode prints as 1.2E+6 this is why in the DB it simply +1 insted of 120 [2008-05-05 17:55:52] sweiss at stylesight dot com You guys *have* to make changes like this more explicitly stated... It took forever to even realize the problem we were having lay with PHP and not the Javascript it was printing it out to - I definitely read the changelog and definitely did not pick up on the fact that all my numbers were going to suddenly come out in this totally useless format now. *Seriously Frustrating* - Couldn't this have just been an ini option for the people that wanted it? [2008-04-18 13:07:41] rbro at hotmail dot com Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: admin at shadowops dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: This bug is not limited to the Round() and related commands. I have been hit by it and it has caused many issues with MYSQL and values entered into the DB. 120 in debug mode prints as 1.2E+6 this is why in the DB it simply +1 insted of 120 Previous Comments: [2008-05-05 17:55:52] sweiss at stylesight dot com You guys *have* to make changes like this more explicitly stated... It took forever to even realize the problem we were having lay with PHP and not the Javascript it was printing it out to - I definitely read the changelog and definitely did not pick up on the fact that all my numbers were going to suddenly come out in this totally useless format now. *Seriously Frustrating* - Couldn't this have just been an ini option for the people that wanted it? [2008-04-18 13:07:41] rbro at hotmail dot com Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: sweiss at stylesight dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: You guys *have* to make changes like this more explicitly stated... It took forever to even realize the problem we were having lay with PHP and not the Javascript it was printing it out to - I definitely read the changelog and definitely did not pick up on the fact that all my numbers were going to suddenly come out in this totally useless format now. *Seriously Frustrating* - Couldn't this have just been an ini option for the people that wanted it? Previous Comments: [2008-04-18 13:07:41] rbro at hotmail dot com Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: rbro at hotmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. Previous Comments: [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 [2008-04-04 17:46:57] admin at vr-realty dot com I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: int-e at gmx dot de Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. Previous Comments: [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 [2008-04-04 17:46:57] admin at vr-realty dot com I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents [2008-03-06 15:56:45] rbro at hotmail dot com I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: rbro at hotmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. Previous Comments: [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 [2008-04-04 17:46:57] admin at vr-realty dot com I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents [2008-03-06 15:56:45] rbro at hotmail dot com I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. [2008-03-04 23:07:43] tech at dragonara dot net We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: marek dot chodor at gmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) Previous Comments: [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 [2008-04-04 17:46:57] admin at vr-realty dot com I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents [2008-03-06 15:56:45] rbro at hotmail dot com I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. [2008-03-04 23:07:43] tech at dragonara dot net We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: ali at adcworks dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 Previous Comments: [2008-04-04 17:46:57] admin at vr-realty dot com I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents [2008-03-06 15:56:45] rbro at hotmail dot com I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. [2008-03-04 23:07:43] tech at dragonara dot net We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: admin at vr-realty dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I had a working database for my office Stock Trading Pool when AAAkkk 1.23E+007. The non programmers there were all freaked the hell out. They thought E meant Error and that we had lost all of our money. trying to tell 70+ people, that haven't seen Scientific notation since they were in 9th grade, that it's not a problem and we will fix it was no easy task. By the time it was brought to my attention people had already started trying to figure out how to sue me for losing their money, yeah it was a mess. And they didn't know that what they see is just a thing for them to see and reference and really could be forgotten and not updated for days. anyways I wen through and changed the MySql DB from floats to VarChars. and type casted the $vars I pulled from the DB to float using $curprice = (float)$price; and the ones that could be int like the number of shares $curshares = (int)$shares; then I did the math $total = (float)($price*$shares); now the General population is feeling at ease and the death threats have subsided. I'm still trying to understand why Scientific notation would come into play. maybe it sould be an obscure function like INT_TO_SCI($var) or num_to_sci($var) .. like the automatic and natural way to have the numbers over millions sould be preserved as a whole long string no matter what the length with the option to convert it to scientific notation if that suits your needs. my 2cents Previous Comments: [2008-03-06 15:56:45] rbro at hotmail dot com I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. [2008-03-04 23:07:43] tech at dragonara dot net We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: rbro at hotmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I agree - to me, this is a BC break that wasn't listed on any changelog or announcement. I have been holding off on upgrading my PHP version to anything later than 5.2.1 because of this issue. Previous Comments: [2008-03-04 23:07:43] tech at dragonara dot net We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 [2008-01-18 21:42:38] nate at recoverydatabase dot net We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: tech at dragonara dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. Previous Comments: [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 [2008-01-18 21:42:38] nate at recoverydatabase dot net We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( [2007-12-29 01:50:56] daniel at fanetworks dot net I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: lhfagundes at gmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 Previous Comments: [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 [2008-01-18 21:42:38] nate at recoverydatabase dot net We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( [2007-12-29 01:50:56] daniel at fanetworks dot net I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( [2007-12-01 08:07:06] owner at dragon-hearts dot net I could see it being desireable to have floats come out in normal or scientific format so maybe a php.ini setting would be in order for this. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: gcleaves at yahoo dot com dot au Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler Previous Comments: [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 [2008-01-18 21:42:38] nate at recoverydatabase dot net We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( [2007-12-29 01:50:56] daniel at fanetworks dot net I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( [2007-12-01 08:07:06] owner at dragon-hearts dot net I could see it being desireable to have floats come out in normal or scientific format so maybe a php.ini setting would be in order for this. [2007-11-30 22:56:22] ross at newgrounds dot com I got bitten by this one too: $rounded = floor(1472 / 1000) * 1000; in PHP 5.1.6, that yields: 1470 in PHP 5.2.5, that yields: 1.47E+7 This is arguably acceptable behavior, but if this is the way it is, it should be a conscious decision, and documented. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: nate at recoverydatabase dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( Previous Comments: [2007-12-29 01:50:56] daniel at fanetworks dot net I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( [2007-12-01 08:07:06] owner at dragon-hearts dot net I could see it being desireable to have floats come out in normal or scientific format so maybe a php.ini setting would be in order for this. [2007-11-30 22:56:22] ross at newgrounds dot com I got bitten by this one too: $rounded = floor(1472 / 1000) * 1000; in PHP 5.1.6, that yields: 1470 in PHP 5.2.5, that yields: 1.47E+7 This is arguably acceptable behavior, but if this is the way it is, it should be a conscious decision, and documented. [2007-11-25 01:22:07] owner at dragon-hearts dot net I have something that is closer to a solution If you replace the /zend/zend_objects.c file with the php-5.2.1 version before compiling php it fixes it. I have tested on php 5.2.2 and php5.2.5 (I assume versions in between will work) and haven't noticed any ill effects but I am only configuring with the following ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs --prefix=/usr/local So I don't know if any other modules will break (though I will test later). Since it's in the Zend folder should I report it to zend? [2007-11-21 17:51:20] craig at craigmayhew dot com Theo's work around does indeed work. sprintf() or number_format() force the number to be displayed in an integer format. Thanks Theo! 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: daniel at fanetworks dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( Previous Comments: [2007-12-01 08:07:06] owner at dragon-hearts dot net I could see it being desireable to have floats come out in normal or scientific format so maybe a php.ini setting would be in order for this. [2007-11-30 22:56:22] ross at newgrounds dot com I got bitten by this one too: $rounded = floor(1472 / 1000) * 1000; in PHP 5.1.6, that yields: 1470 in PHP 5.2.5, that yields: 1.47E+7 This is arguably acceptable behavior, but if this is the way it is, it should be a conscious decision, and documented. [2007-11-25 01:22:07] owner at dragon-hearts dot net I have something that is closer to a solution If you replace the /zend/zend_objects.c file with the php-5.2.1 version before compiling php it fixes it. I have tested on php 5.2.2 and php5.2.5 (I assume versions in between will work) and haven't noticed any ill effects but I am only configuring with the following ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs --prefix=/usr/local So I don't know if any other modules will break (though I will test later). Since it's in the Zend folder should I report it to zend? [2007-11-21 17:51:20] craig at craigmayhew dot com Theo's work around does indeed work. sprintf() or number_format() force the number to be displayed in an integer format. Thanks Theo! [2007-11-21 17:33:32] theo at lomasdavies dot net I am also experiencing this issue. As a work around you can use sprintf or number_format to force it to display correctly. not by any means a fix, but got me out of a jam. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: ross at newgrounds dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I got bitten by this one too: $rounded = floor(1472 / 1000) * 1000; in PHP 5.1.6, that yields: 1470 in PHP 5.2.5, that yields: 1.47E+7 This is arguably acceptable behavior, but if this is the way it is, it should be a conscious decision, and documented. Previous Comments: [2007-11-25 01:22:07] owner at dragon-hearts dot net I have something that is closer to a solution If you replace the /zend/zend_objects.c file with the php-5.2.1 version before compiling php it fixes it. I have tested on php 5.2.2 and php5.2.5 (I assume versions in between will work) and haven't noticed any ill effects but I am only configuring with the following ./configure --disable-all --with-apxs2=/usr/local/apache/bin/apxs --prefix=/usr/local So I don't know if any other modules will break (though I will test later). Since it's in the Zend folder should I report it to zend? [2007-11-21 17:51:20] craig at craigmayhew dot com Theo's work around does indeed work. sprintf() or number_format() force the number to be displayed in an integer format. Thanks Theo! [2007-11-21 17:33:32] theo at lomasdavies dot net I am also experiencing this issue. As a work around you can use sprintf or number_format to force it to display correctly. not by any means a fix, but got me out of a jam. [2007-11-17 20:35:37] owner at dragon-hearts dot net Any idea when this might get fixed, since php5.2.5 has been released cpanel don't support 5.2.1 anymore hence it's not as easy to install 5.2.1 anymore and I'm stuck with 4.4.7 which won't be supported after December causing even more problems. [2007-11-13 13:54:02] rbro at hotmail dot com Yes, I haven't upgraded to the latest PHP 5.2.x for the same reasons as it's causing similar issues for me with dollar amount calculations (e.g. bug 42871). This change seems to have started in recent 5.2.x releases, but I don't recall it being on any changelog or announcement since it is causing backwards-compatibility issues with earlier PHP releases. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: craig at craigmayhew dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Theo's work around does indeed work. sprintf() or number_format() force the number to be displayed in an integer format. Thanks Theo! Previous Comments: [2007-11-21 17:33:32] theo at lomasdavies dot net I am also experiencing this issue. As a work around you can use sprintf or number_format to force it to display correctly. not by any means a fix, but got me out of a jam. [2007-11-17 20:35:37] owner at dragon-hearts dot net Any idea when this might get fixed, since php5.2.5 has been released cpanel don't support 5.2.1 anymore hence it's not as easy to install 5.2.1 anymore and I'm stuck with 4.4.7 which won't be supported after December causing even more problems. [2007-11-13 13:54:02] rbro at hotmail dot com Yes, I haven't upgraded to the latest PHP 5.2.x for the same reasons as it's causing similar issues for me with dollar amount calculations (e.g. bug 42871). This change seems to have started in recent 5.2.x releases, but I don't recall it being on any changelog or announcement since it is causing backwards-compatibility issues with earlier PHP releases. [2007-11-12 15:32:19] owner at dragon-hearts dot net If it's because they're floats why doesn't it happen in earlier versions of php i.e. 5.2.1? It makes migrating from php 5.2.1 to anything higher a nightmare since any site using these numbers will no longer work (i.e. mine didn't if you try and update mysql with what you expect to be a non scientific number i.e 100 and it tries 1E+6 it'll update it with 1 not 100) that causes real problems. [2007-11-12 10:19:01] [EMAIL PROTECTED] The explanation is quite simple: the number are floats. There is not guarantee that "120.00" is actually represented and/or stored like that. In this particular case, "130.00" is stored like "129.99", so there are no zeros to compress. 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: theo at lomasdavies dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: I am also experiencing this issue. As a work around you can use sprintf or number_format to force it to display correctly. not by any means a fix, but got me out of a jam. Previous Comments: [2007-11-17 20:35:37] owner at dragon-hearts dot net Any idea when this might get fixed, since php5.2.5 has been released cpanel don't support 5.2.1 anymore hence it's not as easy to install 5.2.1 anymore and I'm stuck with 4.4.7 which won't be supported after December causing even more problems. [2007-11-13 13:54:02] rbro at hotmail dot com Yes, I haven't upgraded to the latest PHP 5.2.x for the same reasons as it's causing similar issues for me with dollar amount calculations (e.g. bug 42871). This change seems to have started in recent 5.2.x releases, but I don't recall it being on any changelog or announcement since it is causing backwards-compatibility issues with earlier PHP releases. [2007-11-12 15:32:19] owner at dragon-hearts dot net If it's because they're floats why doesn't it happen in earlier versions of php i.e. 5.2.1? It makes migrating from php 5.2.1 to anything higher a nightmare since any site using these numbers will no longer work (i.e. mine didn't if you try and update mysql with what you expect to be a non scientific number i.e 100 and it tries 1E+6 it'll update it with 1 not 100) that causes real problems. [2007-11-12 10:19:01] [EMAIL PROTECTED] The explanation is quite simple: the number are floats. There is not guarantee that "120.00" is actually represented and/or stored like that. In this particular case, "130.00" is stored like "129.99", so there are no zeros to compress. [2007-10-25 13:41:44] [EMAIL PROTECTED] That last comment's script gives the same output for me, there's definately something strange going on here. :) 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: rbro at hotmail dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: Yes, I haven't upgraded to the latest PHP 5.2.x for the same reasons as it's causing similar issues for me with dollar amount calculations (e.g. bug 42871). This change seems to have started in recent 5.2.x releases, but I don't recall it being on any changelog or announcement since it is causing backwards-compatibility issues with earlier PHP releases. Previous Comments: [2007-11-12 15:32:19] owner at dragon-hearts dot net If it's because they're floats why doesn't it happen in earlier versions of php i.e. 5.2.1? It makes migrating from php 5.2.1 to anything higher a nightmare since any site using these numbers will no longer work (i.e. mine didn't if you try and update mysql with what you expect to be a non scientific number i.e 100 and it tries 1E+6 it'll update it with 1 not 100) that causes real problems. [2007-11-12 10:19:01] [EMAIL PROTECTED] The explanation is quite simple: the number are floats. There is not guarantee that "120.00" is actually represented and/or stored like that. In this particular case, "130.00" is stored like "129.99", so there are no zeros to compress. [2007-10-25 13:41:44] [EMAIL PROTECTED] That last comment's script gives the same output for me, there's definately something strange going on here. :) [2007-10-22 16:51:25] rbro at hotmail dot com I am also running into this issue but only for certain float values. The original example posted works correctly for me, but other float values are printed in scientific notation while others aren't. It is related to the issue I reported in bug 42871 which was marked bogus. I am running against php5.2-200710221430. Reproduce code: --- http://bugs.php.net/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: rbro at hotmail dot com Reported By: owner at dragon-hearts dot net Status: Open Bug Type: Math related Operating System: Centos4 PHP Version: 5.2.4 New Comment: I am also running into this issue but only for certain float values. The original example posted works correctly for me, but other float values are printed in scientific notation while others aren't. It is related to the issue I reported in bug 42871 which was marked bogus. I am running against php5.2-200710221430. Reproduce code: --- http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Works fine for me [2007-10-20 15:41:28] owner at dragon-hearts dot net Description: When using mathematical processes on numbers over 1 million the result comes out in scientific notation instead of as a normal integer. Tested on PHP 5.2.1 it works as expected on 5.2.2 and above it doesn't. I checked the change log and nothing is mentioned about this. Reproduce code: --- $var1=1; $var2=700; echo $var1*$var2; Expected result: 700 Actual result: -- 7E+6 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
