Hi internals,
https://github.com/php/php-src/pull/5172 changes var_dump() to use 
serialize_precision instead of precision to dump floating-point numbers.
To recap: serialize_precision defaults to -1, which will print exactly as 
many floating-point digits as are needed to represent the number 
accurately. precision defaults to 14, which will print a shorter but 
potentially inaccurate float representation.
The motivation here is that var_dump() is debugging functionality and 
should print values as accurately as possible. The single most common bug 
report we receive is some kind of variation on:
$sum = 0.1 + 0.2;
var_dump($sum); // float(0.3)
var_dump($sum == 0.3); // bool(false) WTF???
After this change, this would instead be:
$sum = 0.1 + 0.2;
var_dump($sum); // float(0.30000000000000004)
var_dump($sum == 0.3); // bool(false) Makes sense...
I have little hope that developers will suddenly start understanding 
floating-point numbers, but at least this should reduce the amount of 
confusion.
Does anyone see an issue with doing this change?
Regards, 
Nikita
Am 18.02.20 um 12:20 schrieb Nikita Popov:
Hi internals,
https://github.com/php/php-src/pull/5172 changes
var_dump()to use
serialize_precision instead of precision to dump floating-point numbers.To recap: serialize_precision defaults to -1, which will print exactly as
many floating-point digits as are needed to represent the number
accurately. precision defaults to 14, which will print a shorter but
potentially inaccurate float representation.The motivation here is that
var_dump()is debugging functionality and
should print values as accurately as possible. The single most common bug
report we receive is some kind of variation on:$sum = 0.1 + 0.2; var_dump($sum); // float(0.3) var_dump($sum == 0.3); // bool(false) WTF???After this change, this would instead be:
$sum = 0.1 + 0.2; var_dump($sum); // float(0.30000000000000004) var_dump($sum == 0.3); // bool(false) Makes sense...I have little hope that developers will suddenly start understanding
floating-point numbers, but at least this should reduce the amount of
confusion.Does anyone see an issue with doing this change?
You mean apart from people now filing bugs how var_dump() can output 
such a nonsensical number from such an easy equation? And that it again 
shows that PHP is not a real programming language (unlike JavaScript) 
and should never be used at all?
Nope ;-)
Cheers
Andreas
PS: I'd absolutely appreciate the change!!!
                                                          ,,,
                                                         (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+ 
| Andreas Heigl                                                       | 
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" | 
| http://andreas.heigl.org                       http://hei.gl/wiFKy7 | 
+---------------------------------------------------------------------+ 
| http://hei.gl/root-ca                                               | 
+---------------------------------------------------------------------+
Nikita Popov wrote:
Hi internals,
https://github.com/php/php-src/pull/5172 changes
var_dump()to use
serialize_precision instead of precision to dump floating-point numbers.
Hi Nikita,
Thank you so much for doing this! I had wanted to do this for a long 
time, and I actually implemented it and began updating tests a while 
ago, but I never got round to finishing it.
It looks in that PR like you also update debug_zval_dump(), maybe that 
should be mentioned?
The one that gave me pause before and now is print_r(). In principle, it 
is just print but recursive (I assume that's whence the name comes), 
but unfortunately some people use it for debugging, so there might be a 
case for changing it. With that said, it's already a very bad choice for 
debugging due to other things ("1", 1, 1.0 and TRUE look the same, "0", 
0.0, and 0 look the same, "", FALSE and NULL look the same…) that 
precision is the least of the developer's problems if they choose 
print_r(), and it's also not in the spirit of "print but recursive". So, 
it is probably unreasonable to change print_r() here. Maybe we should 
put a massive red "DO NOT USE THIS FOR DEBUGGING" warning on its 
documentation page…
One more thing, does var_export() use serialize_precision already? I 
think it does but haven't checked.
Thanks! 
Andrea