[RFC] [DISCUSSION] More precise float value

Hi Yasuo,

-----Original Message-----
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki
Sent: Sunday, September 20, 2015 11:49 PM
To: Kalle Sommer Nielsen kalle@php.net
Cc: Anatoliy Belsky ab@php.net; Ferenc Kovacs tyra3l@gmail.com;
internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [DISCUSSION] More precise float value

Hi Anatol and Ferenc,

I'm sorry I have not caught this any earlier, but even without
consulting with Anatol, I'm not keen on adding this into 7.0, we are
in RC stage, and I want us to focus on a stable release instead of
adding more potential issues, I suggest you target 7.1 instead in the
RFC.

(Ferenc and Anatol cc'd)

I was expecting this kind of reply for this RFC.
What do you think?

This RFC contains JSON float value precision change for PHP 5.6 so that PHP
would not loose floating number information, as well as more precise float
handling option for PHP 7.0.

FYI, var_dump()'s float precision was changed to use serialize_precision as bug
fix before.

Thanks for the ping. IMHO this is the stuff for 7.1. I actually saw the discussions previously, but was rather thinking you was targeting 7.1 as that was already the time of the feature freeze.

Please keep in mind that we effectively have two RCs to do the remaining stabilizations. And we probably should as much as possible. Because this patch it's rather an enhancement to the current functionality which is not indeed broken - I wouldn't see it as critical for 7.0. It should be voted (and discussed if necessary) for 7.1, so we don't loop away from our current situation.

BTW I also had a comment there in the PR about https://github.com/php/php-src/pull/1455/files#diff-c84859666ff690a113d55ef1899d8bf4R149 - so if mode 0 ignores ndigits, why set it to 17 (or anything else). Seems like an unnecessary action, but snprintf is used quite frequently. But just as a notice on the side.

Regards

Anatol

This proposal adds a new json.precision setting. Why? I've been told that
this is more flexible, which is fair enough, but imho we should have very
strong reasons for introducing new ini settings. Reasons that go beyond
"it
might be useful to someone ... maybe?" So what's the particular use-case
here? Where is it necessary to export inaccurate floating point numbers
in
JSON? And should such a use-case indeed exist, why is this a global
setting
rather than an option of json_encode? Furthermore, note that even without
this new ini option, you always have the option of temporarily changing
serialize_precision for a json_encode call, if you really need it.

I second this remark especially because in my book JSON is just another
form of serialization, hence, it should use the same setting.

Additionally, how is it possible that global ini settings -- which in my
opinion is a sensitive area -- can go through with a 50%+1 vote?

Not exactly a language change as it's changing default just for
serialization and json but it's probably on the edge so will change it to
66 in the next revision... ;)

Cheers

On Mon, May 30, 2016 at 7:28 PM, Nikita Popov nikita.ppv@gmail.com
wrote:

Hi all,

IEEE 754 double cannot express exact float values. That said,
float values expressed by json/serialize/var_export/echo/print
are not precise enough in many cases.

Issues:

• json_encode() uses EG(precision)=14 that truncates float values.
  echo()/print()
  does this as well.
• large EG(precision)/PG(serialize_precision) prints meaningless
  values.

This RFC proposes zend_dtoa()'s 0 mode support which rounds float value
to nearest value.

https://wiki.php.net/rfc/precise_float_value
https://github.com/php/php-src/pull/1455

This change is simple enough for PHP 7.0. IMO.
Comments/suggestions are appreciated!

Hi,

After asking Yasuo, I'm putting forward this RFC to have more precise
float
to string decoding at least in PHP 7.1. I cleaned the RFC up a little bit
and it's targeting just 7.1.

It has been some time since this was announced so I will keep it open
for a
week or two and then plan to start vote.

Thanks for taking over this proposal!

I've already mentioned this on the PR when this was originally proposed,
but bringing it up here as well:

This proposal adds a new json.precision setting. Why? I've been told that
this is more flexible, which is fair enough, but imho we should have very
strong reasons for introducing new ini settings. Reasons that go beyond "it
might be useful to someone ... maybe?" So what's the particular use-case
here? Where is it necessary to export inaccurate floating point numbers in
JSON? And should such a use-case indeed exist, why is this a global setting
rather than an option of json_encode? Furthermore, note that even without
this new ini option, you always have the option of temporarily changing
serialize_precision for a json_encode call, if you really need it.

Please also take a look at this comment on the implementation:
https://github.com/php/php-src/pull/1455#discussion_r53933480

To be honest I have been thinking again about it before posting it. I
thought that it might be good to have at least a voting option or keep it
there for discussion but I don't really mind to drop it and just use just
serialize_precision by default. I know that it was me who suggested
json.precision initialy but it wasn't probably the best idea and it might
be a bit confusing for users. If no one thinks that it's useful and we
should have a vote about it, I will remove it in the next couple of days.

I have updated the RFC and dropped the json.precision part. Instead of
that, there will be a voting option only whether to use serialize_precision
for json_encode.

If there are no other issues, I would like to open voting sometimes next
week.

Cheers

Jakub