Re: [Json] Limitations on number size?

Nico Williams <> Tue, 09 July 2013 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05B0B21F9021 for <>; Tue, 9 Jul 2013 15:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.055
X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-1.244, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K9XSJBPJoGvj for <>; Tue, 9 Jul 2013 15:45:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0559121F8FF8 for <>; Tue, 9 Jul 2013 15:45:28 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 8EB34360075 for <>; Tue, 9 Jul 2013 15:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=tLGqcMOFHok/6Ilxh/hq tia75jQ=; b=nb8qVKLxjxNNaa+DerHbyrWNx0j2wry8zz1xLK71i4UELLnE+9XR ttLtcnoW2ng8dByK+fuoqNi+wiXiq4WIa9Utui8gMFcVdHVTftJJYpJAGcQYvst/ Ierk3bQ7YGZfABxUn6ssIveqNMUhtEDV291lFpyENpnHmTlQKrdopKc=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3A0F536006D for <>; Tue, 9 Jul 2013 15:45:28 -0700 (PDT)
Received: by with SMTP id l18so5215070wgh.2 for <>; Tue, 09 Jul 2013 15:45:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BXAf4hmhEL6zfHmn1GZXlMD8pXQ18dv10e8o7qxrGcA=; b=VbKrc/urL0VirPPypJ8a7FQ3eHYpp4cjvSpvNPyFndnnEF35BlBXm7p6j9+CQZCCVM SxC7P0cyTyizLpXKJFP7yH/5nL7fgGvWYSQIsh5chNau/FPViyJILkb0gPgR/ZQzTedk i/Onnicvftbth4lz9LmBhZz3tYSjeIocNb9mxfmLyB4iJDxsnhPCiaGFP7tsAgKIcftK WYjeUJ7YM8lxVVrHtGdg26dc4SOG/mqFXtW+fZU6m36e9RT/P3QUDdgSRGlMrH4xVo9G cUcEMoKPfHyNjYzMP29Ml9cV5QSXHPVX2yrVWIJqkhz4ZHnQJ+p7RkPM/QF4aTHixI5P ME7w==
MIME-Version: 1.0
X-Received: by with SMTP id z1mr16749376wje.14.1373409926699; Tue, 09 Jul 2013 15:45:26 -0700 (PDT)
Received: by with HTTP; Tue, 9 Jul 2013 15:45:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 9 Jul 2013 17:45:26 -0500
Message-ID: <>
From: Nico Williams <>
To: "Peter F. Patel-Schneider" <>
Content-Type: text/plain; charset=UTF-8
Cc: Bjoern Hoehrmann <>,
Subject: Re: [Json] Limitations on number size?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2013 22:45:34 -0000

On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider
<> 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

 - 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

 - bignum with no loss (subject to some arbitrary max size constraint)