Subject: [Json] WGLC comment about numeric values

From: Nico Williams <[email-masked]>
Date: Fri, 11 Oct 2013 14:35:31 -0500

Note that when such software is used, numbers which are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

s/implementations will/implementations most likely will/

(Because there are implementations that only support 32-bit integers.)

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 13:51:41 -0700

Actually, I think the language should be adjusted to say, rather than
generally “supports IEEE754”, more specifically “supports IEEE765 64-bit
binary (double precision) numbers.  Then the rest falls into place.

On Fri, Oct 11, 2013 at 12:35 PM, Nico Williams <[email-masked]>wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 14:08:34 -0700

How’s this?
==============

This specification allows implementations to set limits on the range and
precision of numbers accepted. Since software which implements IEEE
754-2008 binary64 (double precision) numbers [IEEE754] <#IEEE754> is
generally available and widely used, good interoperability can be achieved
by implementations which expect no more precision or range than these
provide, in the sense that implementations will approximate JSON numbers
within the expected precision. A JSON number which is outside those bounds,
such as 1E400 or 3.141592653589793238462643383279, may indicate potential
interoperability problems since it suggests that the software which created
it it expected greater magnitude or precision than is widely available.

Note that when such software is used, numbers which are integers and are in
the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that
implementations will agree exactly on their numeric values.
==============

---

From: Nico Williams <[email-masked]>
Date: Fri, 11 Oct 2013 16:35:44 -0500

> How’s this?

WFM.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Oct 2013 23:39:16 +0200

On Oct 11, 2013, at 23:08, Tim Bray <[email-masked]> wrote:

> A JSON number which is outside those bounds, such as 1E400 or 3.141592653589793238462643383279, may indicate potential interoperability problems since it suggests that the software which created it it expected greater magnitude or precision than is widely available.

Strike "which is outside those bounds".

> A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems since it suggests that the software which created it it expected greater magnitude or precision than is widely available.

(I don't want to restart the 1.1 discussion :-)

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 14:43:18 -0700

Less is more; WFM.

On Fri, Oct 11, 2013 at 2:39 PM, Carsten Bormann <[email-masked]> wrote:

> > A JSON number which is outside those bounds, such as 1E400 or
> 3.141592653589793238462643383279, may indicate potential interoperability
> problems since it suggests that the software which created it it expected
> greater magnitude or precision than is widely available.
>
> > A JSON number such as 1E400 or 3.141592653589793238462643383279 may
> indicate potential interoperability problems since it suggests that the
> software which created it it expected greater magnitude or precision than
> is widely available.
>

---

From: Jorge Chamorro <[email-masked]>
Date: Sat, 12 Oct 2013 00:07:40 +0200

> (I don't want to restart the 1.1 discussion :-)

You don't want :-), but that's interesting and a *very* common source of problems and surprises. Perhaps what you want to say can be said in a short line. Why don't you try? E.g:

"Fractions in base 10 often can't be represented exactly in a binary format, e.g. 0.1" "IEEE-754 is a binary format"

Or a link to somewhere like <http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems> ?

?

-- 
( Jorge )();

---

From: Jorge Chamorro <[email-masked]>
Date: Sat, 12 Oct 2013 00:18:04 +0200

> "Note that IEEE-754 is a binary format, but JSON represents numbers in base 10"

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Oct 2013 15:34:10 -0700

Those problems and surprises are totally nonspecific to JSON.  Don’t think
it adds value.

On Fri, Oct 11, 2013 at 3:07 PM, Jorge Chamorro <[email-masked]>wrote:

> You don't want :-), but that's interesting and a *very* common source of
> problems and surprises. Perhaps what you want to say can be said in a short
> line. Why don't you try? E.g:
>
> "Fractions in base 10 often can't be represented exactly in a binary
> format, e.g. 0.1" "IEEE-754 is a binary format"
>
> Or a link to somewhere like <
> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems> ?
>
> ?
>
> --
> ( Jorge )();

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 12 Oct 2013 17:09:51 +0900

On 2013/10/12 6:08, Tim Bray wrote:
> precision of numbers accepted.

Fine up to here.

> Since software which implements IEEE
> 754-2008 binary64 (double precision) numbers [IEEE754]<#IEEE754>  is
> within the expected precision.

This sentence is just way too long. The referent of "these" in "than 
these provide" is unclear. I suggest the following rewording:

Software which implements IEEE 754-2008 binary64 (double precision) 
numbers [IEEE754]<#IEEE754> is generally available and widely used.
Therefore, good interoperability can be achieved by implementations 
which expect no more precision or range than provided by these numbers.
This means that implementations will approximate JSON numbers within the 
expected precision.

Regards,   Martin.

> A JSON number which is outside those bounds,

s/it it/it/

> On Fri, Oct 11, 2013 at 1:51 PM, Tim Bray<[email-masked]>  wrote:
>
>> On Fri, Oct 11, 2013 at 12:35 PM, Nico Williams<[email-masked]>wrote:
>>