Hi Yasuo, On Tue, Jul 28, 2015 at 10:51 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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? > > This is certainly not a margin error for GPS and definitely has no influence on Google maps... :) Of course there are cases when you can need slightly bigger precision. What I was trying to say is that you exaggerate the problem. > 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. > > Once again, you have got the option to change it if you don't like the current default. > In addition, it's inconsistent with other data exchange functions. i.e. > serialize/var_export. > json_encode is not serialize nor var_export. It's for different things... I have already said that you might care about output size and if you do, you certainly don't want to be changed in the bug fixing release. > >> >>> 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 > > Again it's not the same. json_encode is much more used the var_export IMHO so the chance that you break someone's code is much bigger. Also it doesn't mean that you did the right thing and it's not a precedence for such change in json. I guess that there wasn't anyone who would disagree with you at that time. > 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. > > We are still compatible. This is recommendation, not requirement. However I have to agree that it will be probably good idea to change default. But just only if agreed in RFC as this is not a bug! Personally I am against changing that to serialize_precision. I'd much prefer introducing new ini (e.g. json_precision) with the same default as serialize_precision. It would give more flexibility and allow changing value just for json. > My position is > - PHP7.0: We must use serialize_precision for JSON > - PHP5.6: I strongly suggest to use serialize_precision for JSON > > I'd prefer 7.1 as this is not something that would be so urgent. As you see we don't agree here. It means that if you want to get it in, please write RFC. You can add the version option as I did it for json numeric to string RFC and you will see if others agree with you that this is a bug. Cheers Jakub >
