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

"Joe Hildebrand (jhildebr)" <> Mon, 19 May 2014 22:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6F7121A03DA for <>; Mon, 19 May 2014 15:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2yWw_puTjlg1 for <>; Mon, 19 May 2014 15:01:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C9561A03DE for <>; Mon, 19 May 2014 15:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2892; q=dns/txt; s=iport; t=1400536878; x=1401746478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=blm3sgZaoV6igaE7k1Vi1nVudN199Rj94PgYTApJpPk=; b=S+m0bQWsSSOv+aOsvMXHN+0rUDlPAoGjUeGbjzoDIF175DCQJjiib3Eu 7jwvi+HgPm7P6dznQV5Iw32IizkxCI5UdzkvPphnC+Z6nPdAwuBUZcTKI F+ciMhJ7Pbvxf07zusiIssR5MrNhYr6HH9DPUa1ji5m+UIV105WL81vCU M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,869,1392163200"; d="scan'208";a="326128005"
Received: from ([]) by with ESMTP; 19 May 2014 22:00:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s4JM0x21025641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Mon, 19 May 2014 22:00:59 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 19 May 2014 17:00:59 -0500
From: "Joe Hildebrand (jhildebr)" <>
To: "Matt Miller (mamille2)" <>
Thread-Topic: [Json] I-JSON Topic #5: Numbers
Thread-Index: AQHPYxzPc1qOL3zAFk6QxZ1T0YrJO5snzN0A//+jtwCAAGnvgIAEImEAgBzCVgD//8VpAA==
Date: Mon, 19 May 2014 22:00:59 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Mon, 19 May 2014 22:01:19 -0000

On 5/19/14, 1:30 PM, "Matt Miller (mamille2)" <> wrote:

>could you provide more detail of what the concern here is?  I suspect
>you have been too terse so far.

You're likely correct.

I said:

> Subnormals are allowed in JSON, I believe.  They probably don't
> interop quite as expected if you're using C and have -O1 or higher
> turned on (for example).

Here's an example of a number that is allowed in JSON, but in some
implementations would lead to a subnormal number:


You'll note that (at least in a couple of the browsers that I checked, as
well as node.js):

JSON.parse("4e-324") == 5e-324

The reason for this is that the minimum "normal" IEEE754 double-precision
floating point number is represented in hex as: 0010 0000 0000 0000, which
corresponds to roughly 2.2250738585072014e−308.  For numbers smaller than
this, precision gets thrown away intentionally, in order to represent
numbers closer to zero.  For example, the smallest number you can
represent this way is 0000 0000 0000 0001 (hex), which corresponds to
roughly 4.94e-324 ... which lets you understand why 5e-324 might be a
reasonable way to render this number as a string.

For some computations, the loss of precision is nice.  For others, you'd
just as soon have zero than a really tiny number.  IEEE-compliant hardware
will set an underflow flag when you get a subnormal result as the output
of a calculation.  However many languages (including C) don't give you
access to this flag.

This problem is exacerbated by the fact that different C compilers at
different optimization settings, at different usages of SSE processor
extensions will either "flush to zero" (FTZ) or not.  If FTZ is enabled,
your JSON parser is likely going to return 0 for JSON.parse("4e-324").

As such, there will be a loss of interoperability for very small numbers
(either positive or negative), and I think we should mention what the
smallest safely-interoperable numbers are.  10^-308 and -10^-308 seem like
reasonable limits in decimal-land.

Joe Hildebrand