Re: [Json] 2-step proposal 4627bis + I-JSON

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 04 July 2013 04:07 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562F521F8D0D for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 21:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.457
X-Spam-Level:
X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5bsimQG1dRD for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 21:07:36 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28521F8A85 for <json@ietf.org>; Wed, 3 Jul 2013 21:07:35 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6447Wm9027309; Thu, 4 Jul 2013 13:07:32 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6ed9_e29f_401dba74_e45f_11e2_b65e_001e6722eec2; Thu, 04 Jul 2013 13:07:31 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 06E88BF548; Thu, 4 Jul 2013 13:05:56 +0900 (JST)
Message-ID: <51D4F4F3.2070305@it.aoyama.ac.jp>
Date: Thu, 04 Jul 2013 13:07:15 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John Cowan <cowan@mercury.ccil.org>
References: <CAHBU6itqGgndUKRUHH_q6fv8jonGL3VVHhkezFne0sC3T12c_Q@mail.gmail.com> <20130704002732.GV32044@mercury.ccil.org>
In-Reply-To: <20130704002732.GV32044@mercury.ccil.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Tim Bray <tbray@textuality.com>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] 2-step proposal 4627bis + I-JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
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, 04 Jul 2013 04:07:42 -0000

On 2013/07/04 9:27, John Cowan wrote:
> Tim Bray scripsit:
>
>> 2. Recharter in a way that will allow us to produce something like a
>> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html
>> Produce something like that. Second victory!
>
> This is a fine trial balloon.  I have two comments:

> 2) Stating the precision of numbers does not suffice: you ought also to
> state explicitly that the valid range is numbers whose absolute value is
> between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive.  For example,
> the integer 4503599627370497 is not exactly representable as a double (it
> is 2^52+1) and ought not to be allowed in I-JSON.  So I still prefer my
> proposal of "is exactly representable as an IEEE 754:2008 64-bit binary
> floating point number".

That doesn't work very well either, because you might need quite a few 
digits after the decimal point to *exactly* represent a binary fraction 
in decimal numbers. As an example, try to write something like
(2**52+1) / 2.0**200 (** being exponentiation)

You'll need something like 50+ digits, but nobody does this. What e.g. 
Ruby does (since about version 2.0) is to produce a representation that 
has just as many digits as necessary to unambiguously have a single 
closest representation in IEEE 754:2008.

Regards,   Martin.