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

"Manger, James" <James.H.Manger@team.telstra.com> Thu, 22 May 2014 00:45 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 79F971A000B for <json@ietfa.amsl.com>; Wed, 21 May 2014 17:45:39 -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 ytgcIw9PFSl3 for <json@ietfa.amsl.com>; Wed, 21 May 2014 17:45:38 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id D1A361A0007 for <json@ietf.org>; Wed, 21 May 2014 17:45:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.98,883,1392123600"; d="scan'208";a="201117190"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 22 May 2014 10:45:36 +1000
X-IronPort-AV: E=McAfee;i="5600,1067,7445"; a="223722826"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccvi.tcif.telstra.com.au with ESMTP; 22 May 2014 10:45:35 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 22 May 2014 10:45:35 +1000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, John Cowan <cowan@mercury.ccil.org>
Date: Thu, 22 May 2014 10:45:33 +1000
Thread-Topic: [Json] I-JSON Topic #5: Numbers
Thread-Index: AQHPYxzPc1qOL3zAFk6QxZ1T0YrJO5snzN0A//+jtwCAAGnvgIAEImEAgBzCVgD//8VpAIAAc5kAgADXt4CAAHQ7oIAAfEKAgABzMQCAAJ9K8A==
Message-ID: <255B9BB34FB7D647A506DC292726F6E1154629E87D@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> <255B9BB34FB7D647A506DC292726F6E115461FFE59@WSMSG3153V.srv.dir.telstra.com> <20140521020731.GG9283@mercury.ccil.org> <CFA21B5C.4A721%jhildebr@cisco.com>
In-Reply-To: <CFA21B5C.4A721%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/FYB6PvrHNyaQezEni4tclU0CJgE
Cc: Carsten Bormann <cabo@tzi.org>, IETF JSON WG <json@ietf.org>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>
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: Thu, 22 May 2014 00:45:39 -0000

>"An I-JSON sender MUST NOT expect a receiver to treat a non-zero number
>whose absolute value is greater than 1e308 or less than 1e-308
>as an exact value.

This is wrong (in its implication that other numbers are exact).
Neither I-JSON nor JSON requires numbers to be held internally as a double. I-JSON simply recognizes that doubles are common so you can expect at least the precision & range of a double. You cannot expect values between 1e-308 and 1e308 to be treated exactly. One receiver might round it to the nearest double, another might use a BigDecimal class (treating it exactly). The non-exactness doesn't change abruptly at 1e308 or 1e-308 either.

--
James Manger