About the theoretical matters regarding the JSON format... the most recent document closest to a standard is RFC 8259. As you can see it's not very formal, and it says nothing about prescribed ranges in which numbers must be represented as integers or floating point numbers, nor anything about required precision.
I think it does. Basically, any implementation should be able to handle "Numbers" in the range of IEEE 754 doubles, minus NaN and ±Infinity. Especially, the range -253+1 to 253-1 should be supported:
The representation of numbers is similar to that used in most programming languages. A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed.
A fraction part is a decimal point followed by one or more digits.
An exponent part begins with the letter E in uppercase or lowercase, which may be followed by a plus or minus sign. The E and optional sign are followed by one or more digits.
Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.
...
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 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.
But then again, any implementation is free to set limits on range and precision.
So technically, I could limit "Numbers" in a JSON implementation to the range 0.00 to 2.55, with a precision of no more than three digits, and could get away storing "Numbers" in a byte.
But I think the spirit of JSON is different. https://www.json.org specifies JSON as being a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. That document can still be found, and it has a very clear definition of the "Number" type in 4.3.20:
The type Number is a set of values representing numbers. In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special “Not-a-Number” (NaN) values, positive infinity, and negative infinity.
Alexander
In reply to Re^2: JSON-XS on quadmath builds of perl
by afoken
in thread JSON-XS on quadmath builds of perl
by syphilis
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |