Re: [Json] Limitations on number size?

Tim Bray <tbray@textuality.com> Tue, 09 July 2013 15:28 UTC

Return-Path: <tbray@textuality.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 5462721F9E9E for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 08:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Tr2UQJ7kp671 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 08:28:02 -0700 (PDT)
Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id C2E7921F9EB6 for <json@ietf.org>; Tue, 9 Jul 2013 08:28:01 -0700 (PDT)
Received: by mail-ve0-f176.google.com with SMTP id c13so4776617vea.35 for <json@ietf.org>; Tue, 09 Jul 2013 08:28:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rYB1VIcoA3LcEtHUEwOdUb04bpKLRdYK7esF5k7SKuY=; b=fOTPiqQdQ8Rop4NL2XJpfWBIJtK6L1zRRvIqG7XOzHZmJWreEYjrKPjZBG1LTzVRnb IG5CI6l+UA9M64hs3JE9Qp0RzAewk4GhQ8BicrJrtb0/zCkJ7TV3zEv4PKwMqEx79BLa KAwZ8lYYbC8X+7XnHO979zhH6kz+siy3LbqcRA5jM9tP/i///nTbyfQOrkPL/s6KDFyd 6Q47Bbn/aiFm/wkBbmJXsEgLe1zp285Lrh0pNG5fLM/hWfutNKRhEYjgT1W2cqAhu9Um sx5xFGZHEHcEm4g/7rk52n4oYM+xAULPnnmrSNdeLTIP32ZaX/q3ue26jWL3A1HvFGxL te9w==
MIME-Version: 1.0
X-Received: by 10.52.90.115 with SMTP id bv19mr13888655vdb.108.1373383680178; Tue, 09 Jul 2013 08:28:00 -0700 (PDT)
Received: by 10.220.219.200 with HTTP; Tue, 9 Jul 2013 08:27:59 -0700 (PDT)
X-Originating-IP: [12.232.193.126]
In-Reply-To: <F142B117-37C4-4936-AE81-D3571AB118C8@tzi.org>
References: <51DC0F95.7010407@gmail.com> <F142B117-37C4-4936-AE81-D3571AB118C8@tzi.org>
Date: Tue, 9 Jul 2013 08:27:59 -0700
Message-ID: <CAHBU6isckD0JCNT66BiS7sWXV3qyUXfseJ1kJk0bSL62QNFkQw@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary=20cf307f38de65cf1804e115cee3
X-Gm-Message-State: ALoCoQkrq919gpMfc5Ahabc4o9MnfU09onLY6w4ILfVwAu7SY8JYRnwdjwKaJ4xeeaawe698AwmP
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "json@ietf.org" <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 15:28:06 -0000

Yeah, we can’t retroactively change the 4627 production for number, nor, in
the -bis, say very much useful aside from a caution that implementations
are all over the map.  When we move on to the BCP or Internet JSON or
whatever, I think the single most interesting discussion will be how to
constrain numeric values for maximum interoperability.

-T


On Tue, Jul 9, 2013 at 7:41 AM, Carsten Bormann <cabo@tzi.org> wrote:

> >  JSON numbers are ECMAScript numbers
>
> That's a common misconception.
>
> JSON numbers are what they are (see the production "number" in RFC 4627).
> JSON numbers obviously are decimal, ECMAScript numbers are binary.
>
> The text then goes on to say "The representation of numbers is similar to
> that used in most programming languages."; most programming languages
> distinguish 0 and 0.0 very heavily, and almost all modern ones have more
> than 53 bits of precision in numbers, but most programming languages also
> use binary numbers for the semantics of that decimal representation.
>
> When generating JSON for high levels of interoperability, you wouldn't
> want to rely on the recipient distinguishing 0 from 0.0, or more generally
> on distinguishing two numbers that differ but map to the same IEEE 754
> double precision number.  Some user communities have done the latter*) and
> I know a lot of parsers that do the former.
>
> > ECMAScript numbers are IEEE floating point doubles (minus some odd bits).
>
> Indeed.
>
> > I was astonished to find out that some people disagree, apparently to
> the point that they believe that 0 is different from .0
>
> .0 is not a JSON number, but 0.0 is.
> Whether that is different from 0 is up to the data model (RFC 4627 is mute
> about that, and I have reason to believe that is intentional); in
> interoperable JSON, it would be foolish to rely on them being different
> (but it is less clear to me how foolish it would be to rely on them not
> being different), in JSON syntax, they clearly are different.
>
> Grüße, Carsten
>
> *) https://dev.twitter.com/docs/twitter-ids-json-and-snowflake
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>