|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #66866 Same output for float numbers when using variable handling functions
Submitted: 2014-03-09 17:21 UTC Modified: 2022-04-22 13:13 UTC
Avg. Score:4.2 ± 0.4
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:0 (0.0%)
From: jan dot kahoun at heureka dot cz Assigned:
Status: Not a bug Package: Variables related
PHP Version: Irrelevant OS: CentOS release 6.4 (Final)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
18 + 12 = ?
Subscribe to this entry?

 [2014-03-09 17:21 UTC] jan dot kahoun at heureka dot cz
I know that the floating point values have a limited precision and hence a value might not have the same string representation after any processing. But it is possible to make var_dump(), print_r() and var_export() functions to output same result for float numbers? Some times the different output results leads to hard debuging ;-)
If this is not possible, please mention this "feature" in the documentation of the functions. 
Thank you.

Test script:
$x = 0.399999999999999855671006798729649744927883148193359375;


Expected result:
Same result for all functions:
print_r() = 0.399999999999999855671006798729649744927883148193359375
var_export() = 0.399999999999999855671006798729649744927883148193359375
var_dump() = float(0.399999999999999855671006798729649744927883148193359375)

Actual result:
print_r() = 0.4
var_export() = 0.399999999999999855671006798729649744927883148193359375
var_dump() = float(0.4)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-03-09 17:31 UTC]
-Type: Feature/Change Request +Type: Documentation Problem
 [2014-03-09 17:31 UTC]
var_export() is fundamentally different from print_r() and var_dump() in that it is often used to read data back in. As such it is closer to serialize() than the others which are display-only functions. For display purposes PHP has the 'precision' ini setting and for serialize-purposes we have serialize_precision. In you script, if you do:

echo ini_set('precision',ini_get('serialize_precision'));

At the top you should get the same value for all three.

But yes, this probably should be mentioned on the var_export doc page.
 [2014-03-09 17:58 UTC] jan dot kahoun at heureka dot cz
But functions var_dump() and print_r() are often used for debuging purpouses. So if you want to see what is actually in the variable you will not expect the rounded value. This is realy confusing.

I think, that this should be at least mentioned on the all doc pages of the functions var_dump(), print_r() and var_export().

Thank you.
 [2014-03-09 18:10 UTC]
echo/print() are used for debugging too all over the place. Having print_r() show a different value would lead to the exact same confusion. The best we can do is do a better job explaining the precision settings on the relevant doc pages.
 [2014-03-09 18:26 UTC] jan dot kahoun at heureka dot cz
Yes, that's true. So maybe it will be better to have same value for setting the "precision" and "serialize_precision" at default? I realy don't know why is better to have lower precision when displaying value? What are the usecases? I thought that for precision purpouses, there are relevant functions like round(), format_number(), ceil() and floor(). 
I'm not the only one who is facing with this strange behaviour. ;-)
 [2018-08-23 18:57 UTC] php at sam002 dot net
This is really misleading.The 'serialize_precision', the default value was recently made '-1'. Also need for 'precision'.
 [2022-04-22 13:13 UTC]
-Status: Open +Status: Not a bug
 [2022-04-22 13:13 UTC]
Since PHP 7.1 var_dump and the like also output the float in full precision. This ini option is documented here:
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 14 10:01:31 2024 UTC