Make var_dump() use serialize_precision

5 years ago by Nikita Popov — view source — reply

unread

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

5 years ago by Andreas Heigl — view source — reply

unread

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 |
+---------------------------------------------------------------------+

5 years ago by Andrea Faulds — view source — reply

unread

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