Re: [Json] Limitations on number size?

"Peter F. Patel-Schneider" <pfpschneider@gmail.com> Tue, 09 July 2013 23:10 UTC

Return-Path: <pfpschneider@gmail.com>
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 E3CDA11E8196 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 16:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.461
X-Spam-Level:
X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166]
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 t5eB3Fy2jhFV for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 16:10:00 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0EC11E8193 for <json@ietf.org>; Tue, 9 Jul 2013 16:10:00 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id up14so7776246obb.14 for <json@ietf.org>; Tue, 09 Jul 2013 16:09:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g2f806kJ9QNF1Ixb3pJAb/KgXyeS+Zb8CnPjnU0qT38=; b=s2IY0gEzZCzK0diaTWp5I6LzbFGeHBLEjkNobhQX27DhTSOi17SvusdhNMGsD6YCE9 pUX8pYKb1QZW9b9ioqv63NxGZoyzFVCGZTQj890TtJYRNHS4DsKon7u8mVCGxFpTPJZt MzffVehjVNZlidT0bf4f+rGbrho3io57AC88qPmL1+p3N9CjnlVs3+iJgsNatuTckZcH jP3DtUNlRXgcqNtwx2SNgPFMrpgDqSHW+3oPuRWr+09nkwghB1+V1tJu+g2IyG2Q8Iu6 t2Zx12VyP9qQ87mh6CLdboAU2OnxSuOUh8oNZcI0lPTgtdCHHUORSO6Zcttvz7uq8N/O GE9g==
X-Received: by 10.182.219.166 with SMTP id pp6mr25973265obc.34.1373411399829; Tue, 09 Jul 2013 16:09:59 -0700 (PDT)
Received: from [192.168.1.102] (out-on-158.wireless.telus.com. [207.219.69.158]) by mx.google.com with ESMTPSA id el16sm41442697oeb.2.2013.07.09.16.09.58 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:09:59 -0700 (PDT)
Message-ID: <51DC9841.9020000@gmail.com>
Date: Tue, 09 Jul 2013 16:09:53 -0700
From: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51DC7F87.6060503@gmail.com> <CAK3OfOjGtZ+OOG+uwOFKSvr3+tD3T5-vKaAkcFAgG+7fm96cdQ@mail.gmail.com>
In-Reply-To: <CAK3OfOjGtZ+OOG+uwOFKSvr3+tD3T5-vKaAkcFAgG+7fm96cdQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, json@ietf.org
Subject: Re: [Json] Limitations on number size?
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: Tue, 09 Jul 2013 23:10:01 -0000

Each of your options provides a single type for what is represented by JSON 
numbers.  However, this doesn't include multiple types, such as
- 64 bit integers plus IEEE 754 64-bit double (for some loss tolerance)

I think that the biggest surprise that I have had with respect to JSON numbers 
was that this multiple typing for JSON numbers was allowed (and maybe even 
common).

This lead to my comments on whether the JSON numbers 1, 1.0, and 1.0E0 
represent the same thing or not.

Peter F. Patel-Schneider


On 07/09/2013 03:45 PM, Nico Williams wrote:
> On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com> wrote:
>> [Somewhat less facetious.]
> I was surprised that needn't have been at all facetious.  JSON
> surprises me all the time.  Since so many parsers have optional
> behaviours, let's explore this path.
>
>> Where does this end?   Do I have to worry about whether, for example, 0.0 is
>> different from 0.00?   (Some people, e.g., numerical analysts, would argue
>> that they are different - the first is 0+-0.05 and the second is 0+-0.005.)
>> Do I have to worry about whether 0.1 is different from 1E-1?  (Some people,
>> e.g., XML-philes, might argue that the first is a decimal and the second is
>> a float or double.) Do I have to worry about whether 0 is different from 0.?
>> (Some people, e.g., C programmers, might argue that 0 is an int and 0. is a
>> float.)
> I think unnecessary leading or trailing zeros, or even zero decimal
> fraction, are fair game to lose.  Such things bear no information if
> all we care about is numbers.  (.0 in some languages implies floating
> point, as opposed to integer, but that's not relevant here.)  Ditto
> negative zero.
>
> Otherwise the tolerance level for information loss in numbers should
> be specified by the application.  We can probably agree on some common
> options that implementations *might* provide.  Here's all the options
> that I think we should consider, but I'm probably missing some:
>
>   - IEEE 754 {32, 64}-bit double with unspecified loss tolerance-- any
> value that can be represented as such no matter what lossage, will be
> accepted
>
>   - IEEE 754 {32, 64}-bit double with no loss in exponent and with N
> digits of precision, with some specified rounding
>
>   - IEEE 754 {32, 64}-bit double with no loss (e.g., 0.1 can't be
> parsed as a double exactly)
>
>   - take the floor of the number as an integer of {32, 64, 128} bits
>
>   - take the floor of the number as bigint (whatever that means for the
> parser / host language) (subject to some arbitrary max size
> constraint)
>
>   - bignum with no loss (subject to some arbitrary max size constraint)