Hi Jakub, On Wed, Jul 29, 2015 at 3:15 AM, Jakub Zelenka <bu...@php.net> wrote:
> On Mon, Jul 27, 2015 at 11:17 PM, Yasuo Ohgaki <yohg...@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 <yohg...@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 yohg...@ohgaki.net
