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

"Manger, James" <James.H.Manger@team.telstra.com> Wed, 21 May 2014 01:36 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF06D1A03FB for <json@ietfa.amsl.com>; Tue, 20 May 2014 18:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmY-O-1atAMp for <json@ietfa.amsl.com>; Tue, 20 May 2014 18:36:19 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11B1A03F6 for <json@ietf.org>; 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 ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2014 11:24:57 +1000
X-IronPort-AV: E=McAfee;i="5600,1067,7444"; a="280451839"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 21 May 2014 11:36:17 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 21 May 2014 11:36:17 +1000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, Carsten Bormann <cabo@tzi.org>
Date: Wed, 21 May 2014 11:36:15 +1000
Thread-Topic: [Json] I-JSON Topic #5: Numbers
Thread-Index: AQHPYxzPc1qOL3zAFk6QxZ1T0YrJO5snzN0A//+jtwCAAGnvgIAEImEAgBzCVgD//8VpAIAAc5kAgADXt4CAAHQ7oA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E115461FFE59@WSMSG3153V.srv.dir.telstra.com>
References: <535EB3BF.8080606@cisco.com> <CAHBU6ivjF9ULW0yGSVdJi2D6QgUThuhym_ZhpgLM=cvLu=mAiQ@mail.gmail.com> <CF841AAE.47D86%jhildebr@cisco.com> <CAHBU6itK5HtSTPWSsHsHUPja90emqU86LsgjrBorkqcUDivS2A@mail.gmail.com> <CF87EB9C.48BB0%jhildebr@cisco.com> <537A5BE0.3020406@cisco.com> <CF9FCEC9.4A4E7%jhildebr@cisco.com> <488AE66E-725D-40B3-9FDA-ADA1018BCF65@tzi.org> <CFA0F09E.4A609%jhildebr@cisco.com>
In-Reply-To: <CFA0F09E.4A609%jhildebr@cisco.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/json/DO8qrorqRs43Jz45MfuTqs6eq6c
Cc: "Matt Miller \(mamille2\)" <mamille2@cisco.com>, IETF JSON WG <json@ietf.org>
Subject: Re: [Json] I-JSON Topic #5: Numbers
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=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]"?

  {"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