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