Make var_dump() use serialize_precision

  108655
February 18, 2020 11:20 nikita.ppv@gmail.com (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?

Regards,
Nikita
  108656
February 18, 2020 12:03 andreas@heigl.org (Andreas Heigl)
--Ub2bE37IAilZODcSkWmt2KRggPkpvhyUk
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable



Am 18.02.20 um 12:20 schrieb Nikita Popov:
> Hi internals, >=20 > https://github.com/php/php-src/pull/5172 changes var_dump() to use > serialize_precision instead of precision to dump floating-point numbers= =2E
>=20 > 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. >=20 > The motivation here is that var_dump() is debugging functionality and > should print values as accurately as possible. The single most common b= ug
> report we receive is some kind of variation on: >=20 > $sum =3D 0.1 + 0.2; > var_dump($sum); // float(0.3) > var_dump($sum =3D=3D 0.3); // bool(false) WTF??? >=20 > After this change, this would instead be: >=20 > $sum =3D 0.1 + 0.2; > var_dump($sum); // float(0.30000000000000004) > var_dump($sum =3D=3D 0.3); // bool(false) Makes sense... >=20 > I have little hope that developers will suddenly start understanding > floating-point numbers, but at least this should reduce the amount of > confusion. >=20 > 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!!! --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --Ub2bE37IAilZODcSkWmt2KRggPkpvhyUk--
  108748
February 24, 2020 23:03 ajf@ajf.me (Andrea Faulds)
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