Re: [Json] I-JSON Topic #5: Numbers

["Manger, James" <[e-mail]>]

>>> 4e-324

>>That is a bad number for interop not because it is out of range, but
>>because it is not something you can get from converting a binary64 into
>>decimal, so it is somewhat arbitrary what happens on the way back.
>>
>>I would be surprised if there are actual interop problems with 5e-324.
>>Consequently, I don’t quite buy a range limit at 1e-308 yet.
>>(It’s a precision limit, in any case.)

>That was just an easy-to-see example.  Longer numbers less than 1e-308
>will also have less precision than you expect for a double, or get rounded
>to zero unexpectedly.

Less precision than an "average" double maybe,
but not less than you *expect* for a double.

The 1e-308 and 1e308 limits for full precision are a key part (and an expected part) of a double.

What isn’t explicitly stated about numbers in I-JSON is a 2^53 limit for integers. I’m not sure how to phrase it. It would have been nice to say "an I-JSON message MUST NOT include a number with only an integer part (no fraction or exponent part) that is greater than 9007199254740992 (2^53)". Unfortunately I don’t think that is viable. The best we can probably do is say that "an I-JSON message MUST NOT expect a receiver to treat an integer as the exact value given (distinct from integers differing by 1) if it is greater than 9007199254740992". 

Are either or both of the following valid I-JSON messages? Do they comply with "SHOULD NOT include numbers which express greater magnitude or precision than a [double]"?

  {"x":123456789012345680000}

  {"y":123456789012345678901}

ECMAScript (at least 5.1) writes numbers in JSON with up to 21 "significant" decimal digits [http://www.ecma-international.org/ecma-262/5.1/#sec-9.8.1]. It can produce the first example (x) so I hope that is valid. 

--
James Manger