Subject: [Json] Proposal for numeric precision in JSON bis

From: John Cowan <[email-masked]>
Date: Wed, 28 Aug 2013 15:07:06 -0400

Tim Bray, Joe Hildebrand, and I have consenus on the following language
to be added to 4627bis about numeric precision, and are presenting it
to the WG:

1) Replace the last paragraph of 2.4 with the following:

   The intended range and precision of a JSON number matches that of an
   IEEE 754:2008 binary64 (double precision) number, to the limit of what
   can be represented in the JSON syntax.  Numeric values that cannot
   be represented as sequences of digits (such as Infinity and NaN)
   are not permitted.  Attempting to represent numbers that cannot be
   exactly encoded as an IEEE 754:2008 binary64 number, such as 1E400 or
   3.141592653589793238462643383279, may cause interoperability problems.

2) In section 4, change the sentence "An implementation may set limits
on the range of numbers" to "An implementation may set limits on the
range and precision of numbers".

This assumes that "may cause interoperability problems" is the language
that the WG will adopt for the other issues.  Another possibility is
"will potentially cause interoperability problems".

-- 
John Cowan          http://www.ccil.org/~cowan         [email-masked]
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING.  Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Aug 2013 21:24:41 +0200

On Aug 28, 2013, at 21:07, John Cowan <[email-masked]> wrote:

>   IEEE 754:2008 binary64 (double precision) number, 

Intended by whom?

The technical content of that half-sentence precisely describes one specific community of JSON users and ignores all others.

Since that community is large, sticking to the range and precision of IEEE 754 doubles does maximize interoperability, and that would be indeed my recommendation for applications that need to work in the widest possible space.

The number system of JavaScript is, however, completely irrelevant to other legitimate uses of JSON as a data interchange format.  If fixating JSON on that number system was "intended", a lot of people have not been telling the truth for a decade.  I don't think you want to insult them by implying that.

Grüße, Carsten

PS.: All finite IEEE 754 doubles can be notated in JSON syntax.

PPS.: Add 1.1 as an example for what "cannot be exactly encoded as an IEEE 754:2008 binary64 number".  I don't believe that interchanging this number causes great interoperability problems in practice, however.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Wed, 28 Aug 2013 12:53:49 -0700

On 08/28/2013 12:24 PM, Carsten Bormann wrote:

[...]

I  would be very cautious about making such statements.

peter

---

From: John Cowan <[email-masked]>
Date: Wed, 28 Aug 2013 16:20:03 -0400

Peter F. Patel-Schneider scripsit:

> PPS.: Add 1.1 as an example for what "cannot be exactly encoded as an
> IEEE 754:2008 binary64 number".  I don't believe that interchanging
> this number causes great interoperability problems in practice, however.

There is a binary64 number which is the closest correspondent to 1.1,
however, namely 0x3f8ccccd.

-- 
John Cowan    http://ccil.org/~cowan    [email-masked]
The work of Henry James has always seemed divisible by a simple dynastic
arrangement into three reigns: James I, James II, and the Old Pretender.
                --Philip Guedalla

---

From: Tony Hansen <[email-masked]>
Date: Wed, 28 Aug 2013 16:19:58 -0400

>    3.141592653589793238462643383279, may cause interoperability problems.

Hmmm, I like the last sentence. But I'm thinking that the first sentence
goes too far in changes to the original spec.

An alternative phrasing could be:

Numeric values that cannot be represented as sequences of digits (such
as Infinity and NaN) are not permitted. To maximize interoperability,
numeric values should be limited to those that may be exactly encoded as
an IEEE 754:2008 binary64 (double precision) binary64 number. For
example, numbers such as 1E400 or 3.141592653589793238462643383279 may
cause interoperability problems.

> "will potentially cause interoperability problems".

I consider the lack of "and precision" to be an oversight in 4627. +1

    Tony Hansen

---

From: John Cowan <[email-masked]>
Date: Wed, 28 Aug 2013 16:32:32 -0400

> cause interoperability problems.

I'm good with that (it's basically what I proposed in the first place to
the sub-WG), except I wouldn't use "should" for fear of confusion
with "SHOULD".

-- 
Do I contradict myself?                         John Cowan
Very well then, I contradict myself.            [email-masked]
I am large, I contain multitudes.               http://www.ccil.org/~cowan
        --Walt Whitman, Leaves of Grass

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Aug 2013 22:33:35 +0200

On Aug 28, 2013, at 22:19, Tony Hansen <[email-masked]> wrote:

> Numeric values that cannot be represented as sequences of digits (such as

(I don't want to be too nitpicky today, but that was one of the things that needed to be corrected in 4627: 1.1 cannot be represented as sequences of digits either...  So the proposal was right to say "cannot be represented in JSON syntax" (which includes [+-e.]), this is just a bit opaque.  Maybe just say:)

> Infinity and NaN) are not permitted.

(I'm sure IEEE 754 has a term for the non-finites, I'm too lazy to look it up.)

> To maximize interoperability,

Yes!

> I consider the lack of "and precision" to be an oversight in 4627. +1

Exactly.

Grüße, Carsten

---

From: Jacob Davies <[email-masked]>
Date: Wed, 28 Aug 2013 13:38:40 -0700

>    3.141592653589793238462643383279, may cause interoperability problems.

Perhaps it would be better to use a more boring number than this one,
to eliminate the possibility of reading this to actually mean pi
rather than just "any old number with a lot of digits after the
decimal point".

---

From: R S <[email-masked]>
Date: Wed, 28 Aug 2013 13:51:01 -0700

On Wed, Aug 28, 2013 at 12:07 PM, John Cowan <[email-masked]> wrote:

>    IEEE 754:2008 binary64 (double precision) number

Is this true? Doesn't seem so.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Aug 2013 23:02:08 +0200

On Aug 28, 2013, at 22:32, John Cowan <[email-masked]> wrote:

>> an IEEE 754:2008 binary64 (double precision) binary64 number.
> 

One possible wording:

# Interoperability can be maximized by limiting numeric values to those...

("Maximize" isn't strictly true, you probably need to stick to what can be represented in a signed (two's complement) 32-bit integer for that, but really "maximizing" is not usually needed.)

# Wide interoperability can be achieved by limiting numeric values to those...

All this could be introduced and motivated by a sentence such as:

# JSON numbers are typically decoded into a number system chosen by the receiving implementation,
# which may set limits on the range and precision of numbers it can represent,
# Not all JSON numbers will then be representable exactly, or at all, in that.

Grüße, Carsten

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Aug 2013 14:34:56 -0700

I really like Carsten’s “Wide interoperability” phrase, and now that I
think of it, losing the term “intended” is probably a good idea.  I’m
neutral on the motivational text; I’m assuming this is something that
everyone knows. -T

On Wed, Aug 28, 2013 at 2:02 PM, Carsten Bormann <[email-masked]> wrote:

> ("Maximize" isn't strictly true, you probably need to stick to what can be
> represented in a signed (two's complement) 32-bit integer for that, but
> really "maximizing" is not usually needed.)
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Stefan Drees <[email-masked]>
Date: Thu, 29 Aug 2013 07:26:01 +0200

Am 28.08.13 23:02, schrieb Carsten Bormann:
> ...

+1 from me for these wordings. Maybe stating (as replacement for the 
former):

Interoperability can be improved by limiting numeric values to those...

I understand interoperability as a finite two state claim (to be or not 
to be) thus forcing a transition from say 90% to 95% interoperability is 
not too useful in the general case, i.e. if you do not care for these 
exact 5% extra "fit" ;-). As any non 100% interoperability may be a 
quest for improval we should be in the classical maximize versus 
satisfice quest - so improve would represent the latter quite well.

What do the others think?

["Stefan"]