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

"Manger, James" <> Wed, 21 May 2014 01:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF06D1A03FB for <>; Tue, 20 May 2014 18:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jmY-O-1atAMp for <>; Tue, 20 May 2014 18:36:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1D11B1A03F6 for <>; Tue, 20 May 2014 18:36:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.98,877,1392123600"; d="scan'208";a="13931054"
Received: from unknown (HELO ([]) by with ESMTP; 21 May 2014 11:24:57 +1000
X-IronPort-AV: E=McAfee;i="5600,1067,7444"; a="280451839"
Received: from ([]) by with ESMTP; 21 May 2014 11:36:17 +1000
Received: from ([]) by ([]) with mapi; Wed, 21 May 2014 11:36:17 +1000
From: "Manger, James" <>
To: "Joe Hildebrand (jhildebr)" <>, Carsten Bormann <>
Date: Wed, 21 May 2014 11:36:15 +1000
Thread-Topic: [Json] I-JSON Topic #5: Numbers
Thread-Index: AQHPYxzPc1qOL3zAFk6QxZ1T0YrJO5snzN0A//+jtwCAAGnvgIAEImEAgBzCVgD//8VpAIAAc5kAgADXt4CAAHQ7oA==
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "Matt Miller (mamille2)" <>, IETF JSON WG <>
Subject: Re: [Json] I-JSON Topic #5: Numbers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 May 2014 01:36:21 -0000

>>> 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]"?



ECMAScript (at least 5.1) writes numbers in JSON with up to 21 "significant" decimal digits []. It can produce the first example (x) so I hope that is valid. 

James Manger