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

From: Matt Miller <[email-masked]>
Date: Mon, 28 Apr 2014 14:02:07 -0600

"draft-i-json-01 says that you MUST not put in a string representing a
number with greater precision/magnitude than IEEE754 doubles can
support.   I think this is a good idea but I'm a little nervous
because I?ve never written the code; if this is unreasonably hard at
either the sending or receiving end someone should say so."

If you have suggestions for better text -- or other comments/concerns
on this language -- please respond to this thread with your
suggestions or reasoning.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

* "How to Argue about I-JSON" <
http://www.ietf.org/mail-archive/web/json/current/msg02775.html >

---

From: Tim Bray <[email-masked]>
Date: Mon, 28 Apr 2014 13:22:54 -0700

It occurs to me that it would be super-useful for the draft to include
explanation of how to follow this rule, including examples of printf and
Java format strings.

On Mon, Apr 28, 2014 at 1:02 PM, Matt Miller <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTXrO+AAoJEDWi+S0W7cO14CgH+wepgV8mwBjeF0GVU64pKR0p
> QGoC4JWHGv0X+6YBRDb/aaBJCHFS9pv+8uZGW39/rBZQecQub+/1EHoef0of/X86
> sWd48We6AWzh35thRw+GpJMjVHT8KP00i/5R4jJSnTvMLh6+wAU5BdBMQu2JGjND
> EFa4xY0yCF9MNYcwLvGXCgmVrSejgvqhd0LYrhY3afr/w1og5ac14qPiZdjNAGql
> dETtwbvoxqIe9OiI21F+0NUNvEFqw5gVASZCrr8Q8UK3GCjyzoabZgUevlrgpY77
> kJkiwmWWTgN8j1OuGWspNWA13t4hTm8HShTjG93NxNtBwi3u6Sy+8gtPggDnTUA=
> =Q7v0
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 28 Apr 2014 20:52:36 +0000

Will we need to talk about subnormals, -0, NaN, Infinity, and the like?

-- 
Joe Hildebrand

---

From: Tim Bray <[email-masked]>
Date: Mon, 28 Apr 2014 14:11:45 -0700

Well, they’re disallowed in JSON let alone i-json so I’d have hoped we can
ignore them.

---

From: Jacob Davies <[email-masked]>
Date: Mon, 28 Apr 2014 14:18:28 -0700

> Will we need to talk about subnormals, -0, NaN, Infinity, and the like?

NaN & infinity yes. Dunno about -0.

I think the burden on the emitter of requiring compliance is low. In
Java AFAIK it's just a case of checking that the value is a legal
double value, is not NaN and not infinite, and converting it with
default toString() (you can trim ".0" from the end if present for
neatness). On the receiver I think it would be rather more difficult.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Apr 2014 06:51:46 +0200

I still have no idea what that MUST is supposed to mean.  Is 1.0 in, 1.000 out?  1.0000000000000000000000000?  Does it mean I can't write 1000000000000000000 but need to write 1e21 instead?  Actually, both numbers cannot be represented in binary64. 
Repeat with 1.1, 1.1000000, 1.100000000000000000000 etc.

Maybe what is meant here is excluding a number that doesn't round trip as a binary64?
But whether that is true depends on rounding rules etc. that aren't defined for JSON.
(There are several ways to write a binary64, e.g. 1.1 vs. the exact form of the number you get from rounding that into binary64.)

If that is supposed to be a MUST, there needs to be a testable definition.

Really, what needs to be excluded is the *intention* to obtain more precision! and there is no way to see whether there was such an intention from the actual JSON text. 

Oh, and 1e400 is a way to interchange Infinity in some JSON implementations, so this is not just about precision, but also about range.

Sent from my iPad

> On 28.04.2014, at 23:18, Jacob Davies <[email-masked]> wrote:
>

---

From: John Cowan <[email-masked]>
Date: Tue, 29 Apr 2014 13:07:27 -0400

> explanation of how to follow this rule, including examples of printf and

I don't think that can be done for C: the behavior of sprintf on floats
is woefully underspecified.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)

---

From: John Cowan <[email-masked]>
Date: Tue, 29 Apr 2014 13:08:42 -0400

> Will we need to talk about subnormals, -0, NaN, Infinity, and the like?

I think -0 is the only issue here.  The combination of a MUST and a SHOULD
pretty much covers everything else.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
But the next day there came no dawn, and the Grey Company passed on
into the darkness of the Storm of Mordor and were lost to mortal sight;
but the Dead followed them.          --"The Passing of the Grey Company"

---

From: John Cowan <[email-masked]>
Date: Tue, 29 Apr 2014 13:15:02 -0400

> Maybe what is meant here is excluding a number that doesn't round trip as a binary64?

That's what the MUST means.  The SHOULD means something different.

> Really, what needs to be excluded is the *intention* to obtain more
> precision! and there is no way to see whether there was such an
> intention from the actual JSON text.

No, there isn't, that's why the MUST is a constraint on emitters, and it is
precisely a constraint on what they expect rather than on what they do.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Apr 2014 10:33:50 -0700

<no hat>

> because I've never written the code; if this is unreasonably hard at

From the comments so far, it seems like it is not clear how to make such restrictions in some languages. If we can't be definitive about what we mean, we should remove it. RFC 7159 has pretty strong wording already.

--Paul Hoffman

---

From: Stefan Drees <[email-masked]>
Date: Wed, 30 Apr 2014 08:04:00 +0200

Am 29.04.14 19:33, schrieb Paul Hoffman:
> From the comments so far, it seems like it is not clear how to make
> such restrictions in some languages. If we can't be definitive about
> what we mean, we should remove it. RFC 7159 has pretty strong wording
> already.

from another context I remember, that being definitive here is 
complicated (at least when a generic consumer of the message is assumed)

1.
There are clients that simply cannot digest a number being larger than 
IEEE754 doubles. In a robust scenario, I would expect, that in that 
case, they reparse that token as a decorated (client side) string and 
try to apply local rules in handling what has been received in that "slot".

2.
Clients that can digest numbers of arbitrary length on the other hand 
would be "slowed down" when all numbers not fitting in IEEE754 doubles 
would be string-wrapped.

3.
JSON strengths are not with types or schemas, but it also helps the 
client, when every value of identically named keys or constituents of 
arrays are of the same "kind" at least in moretrusted setups.

So for me it would be ok to remove it, as no matter how we resolve it, 
from the above mentioned 3 "viewpoints" there are always some "local 
rules" or extra effort involved to handle the general case, which we 
must describe or leave out.

{"stefan": "All the best."}