Grokbase › Groups › PHP › php-internals › May 2016
FAQ

On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki 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.

Cheers

Jakub

Search Discussions

  • Nikita Popov at May 30, 2016 at 6:28 pm ⇧

    On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka wrote:
    On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki 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

    Regards,
    Nikita
  • Fleshgrinder at May 30, 2016 at 6:47 pm ⇧

    On 5/30/2016 8:28 PM, Nikita Popov wrote:
    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?

    --
    Richard "Fleshgrinder" Fussenegger
  • Jakub Zelenka at May 30, 2016 at 7:07 pm ⇧

    On Mon, May 30, 2016 at 7:46 PM, Fleshgrinder wrote:
    On 5/30/2016 8:28 PM, Nikita Popov wrote:
    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
  • Jakub Zelenka at May 30, 2016 at 7:02 pm ⇧

    On Mon, May 30, 2016 at 7:28 PM, Nikita Popov wrote:
    On Mon, May 30, 2016 at 6:34 PM, Jakub Zelenka wrote:
    On Fri, Sep 4, 2015 at 1:41 AM, Yasuo Ohgaki 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.

    Cheers

    Jakub

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 30, '16 at 4:34p
activeMay 30, '16 at 7:07p
posts5
users3
websitephp.net

3 users in discussion

Jakub Zelenka: 3 posts Nikita Popov: 1 post Fleshgrinder: 1 post

Content

People

Support

Translate

site design / logo © 2018 Grokbase