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

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 <jacob@well.com> wrote:
> 
> On Mon, Apr 28, 2014 at 1:52 PM, Joe Hildebrand (jhildebr)
> <jhildebr@cisco.com> wrote:
>> 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.
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
> 