3 ms·
Hit F12 on chrome and enter the following: JSON.parse('[9223372036854775805]')[0] === JSON.parse('[9223372036854775806]')[0] You should get: <- true
by dmm 9y ago
Hit F12 on chrome and enter the following:
JSON.parse('[9223372036854775805]')[0] === JSON.parse('[9223372036854775806]')[0]
You should get:
<- true
Is chrome's implementation broken? Those are both numbers that a signed int64 can store precisely but a double float cannot.
- colanderman 9y agoYes, the JavaScript JSON parser is broken (in design), in that it silently loses data/precision of JSON numbers. JSON numbers are not "int64s" or "double floats", they are arbitrary-precision decimal values. [1] Postgres is the only popular system with built-in JSON functionality that I know of to correctly round-trip JSON numeric data. Python comes close but fails for any number with a decimal point or in E-notation. One can argue that the JSON spec is too permissive (and I would disagree, though I'm somewhat a purist). Or a pedant could note that the JSON spec doesn't actually say whether any of the digits in a number are considered to carry information (and does in fact note that many parsers are faulty). But it's unfortunately true that most popular JSON parsers fail to round-trip valid JSON data due to flawed design. [1] http://json.org/ http://json.org/
- dragonwriter 9y ago> Or a pedant could note that the JSON spec doesn't actually say whether any of the digits in a number are considered to carry information RFC 7159 not only specifies that all of the digits carry information, it specified exactly what information they carry. However, it also expressly permits implementations to limit the range and precision of numbers accepted, recommending (but not requiring) range and precision at least equivalent to IEEE 754 float64 be supported.
- colanderman 9y ago> RFC 7159 not only specifies that all of the digits carry information, it specified exactly what information they carry. Can you quote? I don't see where it does, except by reference to common knowledge. But I should clarify. There are several inefficiencies in JSON numeric representation which may or may not be considered significant by an application. The ones I can think of, in order from "obviously not" to "well, maybe": 1. the case of "e" vs. "E" 2. the optional "+" sign after "e" or "E" 3. presence/absence of decimal point and/or E-notation (shouldn't make a difference, but does in many parsers, such as Python's) 4. the value of the exponent itself (e.g. 3.14 vs. 314e-2) 5. "-" sign in front of any number with a value of 0 (IEEE floats and ones-complement integers do have a negative zero) 6. excess trailing 0 digits after the decimal place (may be used to represent significant figures in scientific applications) 7. digits of lesser significance (obviously the most contentious) JavaScript ignores all but #5. Python ignores all but #3, and due to #3, sometimes #5 and #7. PostgreSQL `json` ignores none; `jsonb` ignores all but #6 and #7. Personally I would draw the line between #4 and #5. But neither the RFC nor the ECMA spec tell us.
- hyperpape 9y agoOne of the multiple JSON specs indicates that implementations are free to introduce limits on precision or range of numbers: https://tools.ietf.org/html/rfc7159#section-3 https://tools.ietf.org/html/rfc7159#section-3.
- colanderman 9y agoI concede that "broken" is too strong a word. "Subpar" would be more accurate. Like a 7-bit MIME gateway in an 8-bit world.
- dragonwriter 9y agoNo, JavaScript simply has inadequate numeric support. Chrome’s implementation is fine (within spec) and makes the natural choice for a general purpose JSON implementation for JS.