Re: [Json] Limitations on number size?

Tatu Saloranta <tsaloranta@gmail.com> Tue, 09 July 2013 21:34 UTC

Return-Path: <tsaloranta@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 77CEB11E816D for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 14:34:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 eSoOkL9zFpgh for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 14:34:13 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 49C5511E8156 for <json@ietf.org>; Tue, 9 Jul 2013 14:34:13 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hq4so5622123wib.2 for <json@ietf.org>; Tue, 09 Jul 2013 14:34:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=roM69oBTl5XerSJuVj9djgV8T5vAxVfnv38gOQ3MSjE=; b=pZpg3bmwoewdmhVO8hGQrXJ8FVZ1Rb38oHx5et4S/OTkfs6URNUuHdhZupWZOeDfZa ApW/zuohU7bwivQt+qi+pegETNT6Vf6rBB3KZv0dmGmZDUxbVocVVM2anV+4C4Pi1RXj qHOL/xDEZEL9cJpqzxcOKln1z2+evgvum+1+7CN12L+ztbxbyWwiG0bhMcBvN50y+UCB fdVVxidvTSk/Sv/rgXQfNzvNKgyp/SAMQkkJK5eZU2UTa/B5uA3OQlr1CzxgmcxnBqHn qpPtrq+8kkQFQBpNdtXNyPy7C4WF/hdupUw69qW+VfwLito7fJkl9O4uk/419HYfvlQ2 mVFg==
MIME-Version: 1.0
X-Received: by 10.180.206.70 with SMTP id lm6mr33189331wic.50.1373405652300; Tue, 09 Jul 2013 14:34:12 -0700 (PDT)
Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 14:34:12 -0700 (PDT)
In-Reply-To: <51DC7F87.6060503@gmail.com>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51DC7F87.6060503@gmail.com>
Date: Tue, 9 Jul 2013 14:34:12 -0700
Message-ID: <CAGrxA24v5L7oCGxEOwecJSLCNiLrSWSt=jFJMA0M9E8fztNLag@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c265be09ba5704e11aec99
Cc: Nico Williams <nico@cryptonector.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, "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 21:34:14 -0000

I am surprised you came to this conclusion, since I assumed we were finally
getting rid of misconception that JSON is closely tied to Javascript.

This is not to say that the way JSON (under-)defines numbers is optimal;
but at this point forcing castrated version of numbers -- which would lead
to practical problems like preventing use of 64-bit longs for timestamps --
would be counter-productive and to me a non-starter.

-+ Tatu +-



On Tue, Jul 9, 2013 at 2:24 PM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> [Somewhat less facetious.]
>
> 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.)
>
> Searching for answers to these questions lead me various bits of RFC 4627.
>
> I looked at "The representation of numbers is similar to that used in most
> programming languages."  However, the only programming language that I was
> acquainted with that had a single number type encompassing scientific
> notation was LISP.   Most other languages that I could recall, e.g., C,
> C++, and ML, had at least a distinction between integers and floats.   Java
> sort of splits the difference.   So this really didn't provide me with any
> guidance.
>
> This lead me to the beginning of the document and the "is derived from the
> ECMAScript Programming Language Standard" and the "JSON defines a small set
> of formatting rules for the portable representation of structured data."
>
> Finally, some guidance!  Hopefully ECMAScript will tell me how numbers in
> JSON can be portably interpreted as data.   So I read the ECMAScript
> document.  Success!  The ECMAScript document tells me, in gory detail, how
> to interpret something that looks like JSON numbers and, moreover, provides
> a datatype for these numbers, namely IEEE floating point double.
>
> So that is how I came up with JSON numbers being IEEE floating point
> double.
>
> Imagine my surprise when I was told that my reasoning was not correct.
>
> Peter F. Patel-Schneider
>
>
>
> On 07/09/2013 09:37 AM, Nico Williams wrote:
>
>> On Tue, Jul 9, 2013 at 11:23 AM, Bjoern Hoehrmann <derhoermi@gmx.net>
>> wrote:
>>
>>> I think it is well-understood that if you need particularily small,
>>> big, precise or otherwise unusual numbers in JSON then it's best to
>>> encode them as strings so you can do the string-to-number conversion
>>> at a higher level than whatever JSON library you might be using today.
>>>
>> <semifacetious>
>> If that's what we should always do then why can't parsers do it
>> automatically?
>> </semifacetious>
>> ______________________________**_________________
>> json mailing list
>> json@ietf.org
>> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>>
> ______________________________**_________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>