php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44223 round() sometimes returns value in E notation
Submitted: 2008-02-22 22:20 UTC Modified: 2008-03-13 20:01 UTC
From: kjohnson at zootweb dot com Assigned:
Status: Not a bug Package: Math related
PHP Version: 5.2.5 OS: Linux 2.6.20.2
Private report: No CVE-ID:
Password:
Status:
Package:
Bug Type:
Summary:
From: kjohnson at zootweb dot com
New email:
PHP Version: OS:

 

 [2008-02-22 22:20 UTC] kjohnson at zootweb dot com
Description:
------------
For certain values, not necessarily large numbers, round() returns the value in exponential notation instead of the usual decimal format. Some of these "special" values are 1200000, 1400000, 2300000, 2400000.

It seems to be just certain multiples of 100,000. Generate your own list with the code below. I suggest you start with input of:
Start = 1000000
Increment = 100000
Iterations = 100 to 200

Reproduce code:
---------------
<html><head><title></title></head><body>
<form method="post" action="<?=$_SERVER['PHP_SELF']?>">
<!-- some recommended values for next fields: 1000000, 100000, 200 -->
Start value:<input type="text" name="start"> &nbsp;&nbsp;
Increment: <input type="text" name="increment"> &nbsp;&nbsp;
Iterations: <input type="text" name="iterations">
<input type="submit">
</form>
<?
if(count($_POST)) {
  echo "<p>Start: ", $_POST['start'], "; Increment: ", $_POST['increment'], "</p>";

  $tmp = $_POST['start'];
  echo round($tmp),"<br>";
  for($i = 0; $i < $_POST['iterations']; $i++ ) {
    $tmp += $_POST['increment'];
    echo round($tmp),"<br>";
  }
}
?>
</body></html>

Expected result:
----------------
All values to be returned in standard decimal format, e.g., "1200000".

Actual result:
--------------
Certain values are returned in exponential format, e.g., "1.2E+6".

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-25 16:08 UTC] kjohnson at zootweb dot com
Thanks for your response!

Sorry, I am not able to change my PHP version, so I can't try the CVS snapshot.
 [2008-03-06 18:44 UTC] a dot u dot savchuk at gmail dot com
bug is not fixed yet in php-5.2.5

$ ./sapi/cli/php ./test1.php | grep 'E+'
1.2E+6
1.4E+6
2.3E+6
2.4E+6
2.8E+6
3.3E+6
3.4E+6
3.8E+6
4.1E+6
4.3E+6
4.6E+6
4.8E+6
5.1E+6
5.3E+6
5.6E+6
5.8E+6
6.1E+6
6.3E+6
6.6E+6
6.8E+6
7.1E+6
7.3E+6
7.6E+6
7.8E+6
8.1E+6
8.2E+6
8.6E+6
8.7E+6
9.1E+6
9.2E+6
9.6E+6
9.7E+6

test script is:

$ cat ./test1.php
<?php
for( $tmp = 0, $i = 0; $i < 100; $i++ ) {
    $tmp += 100000;
    echo round($tmp),"\n";
}
?>

php version is:

$ ./sapi/cli/php -v
PHP 5.2.5 (cli) (built: Mar  2 2008 02:27:40) (DEBUG)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
 [2008-03-13 12:14 UTC] jani@php.net
I don't see any bug here, it's perfectly normal to _print_ it that way since those are floats. 
 [2008-03-13 12:14 UTC] jani@php.net
Hint: Try replacing the 'echo' with var_dump()..
 [2008-03-13 20:01 UTC] kjohnson at zootweb dot com
Thanks for your response, Jani.

OK, so it's not a bug. Would you agree that:

1. It is a change in behavior from PHP 4?
2. This change in behavior is undocumented?

This behavior is not normal when compared to the behavior in PHP 4.

I would not call erratic changes in the format of return values "normal" in any case, since I have never seen anything like this before in other languages.

And, yes, it is only _printing_, but _printing_ counts.

Here's an example of how _printing_ counts. My code that ran fine on PHP 4 suddenly threw an error on PHP 5. This code for a financial transaction used to work just fine, now it breaks for certain values when writing those values into xml, since the value no longer validates against the xsd when round() returns the value in exponential notation:

'<AnnualIncome>' . round($income) . '</AnnualIncome>'

Thanks, again, for responding.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC