Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87356
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.181 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEKnhAEoVNqs6omdZgYHcX1wG3Q9VFvGciptJtr8CZJG92mG_A@mail.gmail.com>
References: <CAGa2bXYgtZ8PZbmFD5hs2gj7b+MTM8-s1DvK+P5dhCU5y+W6Hw@mail.gmail.com>
 <CAEKnhAGfuy6G92=Ng4bbSOOP-mE2t5_cNXnY0QpgHnu-i4Mfjg@mail.gmail.com>
 <CAGa2bXZY3HvXd0yRaG6g-Ewuya+iLc3dsYtJFMfn9FiAbo27tA@mail.gmail.com>
 <CAAyV7nGdAKLmJG81dnG_cGDDCLduMV3gJta+YgwNp5MJ414OJQ@mail.gmail.com>
 <CAGa2bXaWu5uaa2kRvrmnO-JWsCq-uTeQUCNGvafOqHi4c4D7AA@mail.gmail.com>
 <CAGa2bXYMffoBdnh_0HmyQv23KZtsb5RWpJqjosKFa0p_66+vaQ@mail.gmail.com> <CAEKnhAEoVNqs6omdZgYHcX1wG3Q9VFvGciptJtr8CZJG92mG_A@mail.gmail.com>
Date: Wed, 29 Jul 2015 06:51:07 +0900
Message-ID: <CAGa2bXZLBNTXQSyA7p6dt9rgR7W_bpexz8n3HNfApGfQJPm_ng@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11490eb805ec12051bf67a7d
Subject: Re: [PHP-DEV] json_decode/encode should return full precision values
 by default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11490eb805ec12051bf67a7d
Content-Type: text/plain; charset=UTF-8

Hi Jakub,

On Wed, Jul 29, 2015 at 3:15 AM, Jakub Zelenka <bukka@php.net> wrote:

> On Mon, Jul 27, 2015 at 11:17 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>>
>> Get JSON data from Google maps and store the data using PHP, then
>> users lose last 2 digits of fraction part by default. The value is
>> changed
>> and wrong. This is definitely a bug.
>>
>>
> I don't really get why you use Google maps as an example. Do you actually
> know what's the difference between two distances that differs after
> rounding with precision 14?
>
> I just tried it on
> http://www.ig.utexas.edu/outreach/googleearth/latlong.html and set
>
> Lat 1: 51.602097123457   ; Long 1:  -0.120667
> Lat 2: 51.602097123458   ; Long 2:  -0.120667
>
> The difference is 1.114e-10 km which is 0.0001114 millimetres. Are you
> actually serious about that? :)
>

It's error margin for GPS. How about scientific values?

I'm not comfortable with that values aren't processed/stored correctly (as
much as possible.
You know float can't be exactly precise) Even if GPS values may ignore some
fractions,
I'm very uncomfortable with ignoring/destroying original values while it
could be stored
exactly as it is.

In addition, it's inconsistent with other data exchange functions. i.e.
serialize/var_export.


>
>
>
>> We can write
>>
>> $old = ini_set('precision', 17);
>> json_encode($var);
>> ini_set('precision', $old);
>>
>
> You can set it once in your ini file if you need such precision.
>

It's not a good idea. Most PHP codes depend on 14 precision and programmer
cannot assure other code works as expected.


>
>
>>
>> everywhere to workaround this problem.
>>
>> Question is "Is this the way it should be?".
>>
>>
> I have already said that using precision ini wasn't the best idea. However
> json_encode is not the same as serialize and we should not ever change its
> output in a bug fixing release. Doing that could cause also other issues as
> this is a BC break. Lets imagine that someone set low precision on purpose
> just to limit precision and save some space
>

I've been fixed var_export precision issue as a bug.

[yohgaki@dev php-src]$ git show 3cf2682083fc1c8635b02c4c
commit 3cf2682083fc1c8635b02c4cf77bdf12c5e5da35
Merge: 5c89d5a 4c45e95
Author: Yasuo Ohgaki <yohgaki@php.net>
Date:   Tue Oct 29 17:30:58 2013 +0900

    Merge branch 'PHP-5.5'

    * PHP-5.5:
      Fixed Bug 64760 var_export() does not use full precision for
floating-point numbers

Although I don't strongly insist merging fix to 5.6 branch, I think data
exchange function
that is not trying to be precise is bad thing.


> when transferring data . If you change it, then it's screwed up because it
> will use different ini. We don't know what people do in their code and we
> should not break it. As I said this is not a bug but we could consider
> changing that if the RFC proposing such change passes.
>

Strong json numeric validator may have problem with the change. However,
JSON RFC states

6.  Numbers
 This specification allows implementations to set limits on the range
   and precision of numbers accepted.  Since software that implements
   IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
   generally available and widely used, good interoperability can be
   achieved by implementations that expect no more precision or range
   than these provide, in the sense that implementations will
   approximate JSON numbers within the expected precision.  A JSON
   number such as 1E400 or 3.141592653589793238462643383279 may indicate
   potential interoperability problems, since it suggests that the
   software that created it expects receiving software to have greater
   capabilities for numeric magnitude and precision than is widely
   available.

   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.
https://tools.ietf.org/html/rfc7159

In order PHP to be more compatible, we should use IEEE 754 range or
our other data exchange standard, which is serialize_precision=17.

My position is
 - PHP7.0: We must use serialize_precision for JSON
 - PHP5.6: I strongly suggest to use serialize_precision for JSON

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11490eb805ec12051bf67a7d--