Re: [Json] I-JSON Topic #5: Numbers

Tim Bray <> Thu, 22 May 2014 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A14751A0178 for <>; Thu, 22 May 2014 08:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ex5NGPuII-0H for <>; Thu, 22 May 2014 08:48:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF1961A01DD for <>; Thu, 22 May 2014 08:48:13 -0700 (PDT)
Received: by with SMTP id il7so4678894vcb.18 for <>; Thu, 22 May 2014 08:48:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PDbPhJgFNJsS+itYTg2/GGRx8wsiflfWH4mZIDxSg0k=; b=PRBHbHmb6TXbZEomAqtNJlJaVYSsdtH3AcGdeZedM3NhXx0pplxvIZNJ6MyLQPeqQt AK8Q15hSso/E7HRJ1uQJH7+SvG4CvfmMttZKz9M/WtoMAfJ9hgsZqCxzLEUbZHlFHLhs Lf7yYeoxkAdgyxwGCK/KAIeJ5MXQN9Rq6E0GKJ2gzflpr0EGipFuZDMyX/GUHx80RRvB f5V4CRjevhirCKhKLUe6iBMEchYOUJtfP6Wa2ZdaH7fdaF0k7rTbR8kcCs++P0i9hGyU bOeZ4ijrYKbjexCps1gI9zJxQcacvu2/EB9flawZPu/mXSHz2wmCRSSuQaulW0bCUHt5 veyw==
X-Gm-Message-State: ALoCoQnytPoRzmNb/dhvi+/J1FMr5Y9/+M2UrHLhqMVqEzbAILjMQWqEO5En+dC3SkeZkV/l3YCe
X-Received: by with SMTP id p1mr975678vek.69.1400773691891; Thu, 22 May 2014 08:48:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 May 2014 08:47:51 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tim Bray <>
Date: Thu, 22 May 2014 10:47:51 -0500
Message-ID: <>
To: "Manger, James" <>
Content-Type: multipart/alternative; boundary=089e013cc4a450fa0e04f9ff0afd
Cc: Carsten Bormann <>, "Matt Miller \(mamille2\)" <>, John Cowan <>, "Joe Hildebrand \(jhildebr\)" <>, IETF JSON WG <>
Subject: Re: [Json] I-JSON Topic #5: Numbers
X-Mailman-Version: 2.1.15
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: Thu, 22 May 2014 15:48:19 -0000

​Since I don’t pretend to much expertise in the finer points of numeric
representation, let me play referee.  I draw your attention to which is what
we’re trying to improve here.
- I think the second para, saying “Use strings if your numbers are too
big/precise”, is uncontroversial.
- I think the current first paragraph is also reasonably OK in the sense
that what it says is in fact correct.
- There is also a substantial body of knowledge around the number-wrangling
facts such as that there are lots of nice simple short decimally-expressed
numbers that are not going to round-trip.
- Also, the language in RFC7159 makes useful points such as what range of
integers will successfully round-trip and it is effectively included by

My take-away is that leaving the text as in i-json-01 would not be
terrible.  On re-reading this thread, I’m not sure I see any single
suggestion for expanding that text that someone else hasn’t successfully
nit-picked, except for John’s

"An I-JSON sender MUST NOT expect a receiver to treat a non-zero number
whose absolute value is greater than 1e308 or less than 1e-308
as an exact value.  Furthermore, an I-JSON sender MUST NOT expect a
receiver to treat an integer whose absolute value is greater than
9007199254740992 as an exact value."

And I'm not even sure that really adds much value.  If we start enumerating
all the gotchas that can getcha when you’re converting textual and binary
representations of numeric quantities back and forth, this is gonna be a
big long text.

On Wed, May 21, 2014 at 7:45 PM, Manger, James <> wrote:

> >"An I-JSON sender MUST NOT expect a receiver to treat a non-zero number
> >whose absolute value is greater than 1e308 or less than 1e-308
> >as an exact value.
> This is wrong (in its implication that other numbers are exact).
> Neither I-JSON nor JSON requires numbers to be held internally as a
> double. I-JSON simply recognizes that doubles are common so you can expect
> at least the precision & range of a double. You cannot expect values
> between 1e-308 and 1e308 to be treated exactly. One receiver might round it
> to the nearest double, another might use a BigDecimal class (treating it
> exactly). The non-exactness doesn't change abruptly at 1e308 or 1e-308
> either.
> --
> James Manger
> _______________________________________________
> json mailing list

- Tim Bray (If you’d like to send me a private message, see