Re: [Json] 2-step proposal 4627bis + I-JSON

Languages like Ruby and Lisp are pretty well proof against almost any
imaginable numeric representation.

But programmers in statically typed languages are going to do the
equivalent of org.json.JSONObject.getLong() or getDouble(), and the idea in
I-JSON is that if something in a JSON body is a number, it should Just
Work.  So I’m beginning to like John’s idea.  Although it might be
plausible to also say that if the number has no fractional part, it MUST
fall in the 64-bit integer value range.

But anyhow, this is premature.  Let’s hear some input from our chairs & ID
as to what the WG should be trying to produce. -T

On Wed, Jul 3, 2013 at 9:07 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>wrote:

> On 2013/07/04 9:27, John Cowan wrote:
>
>> Tim Bray scripsit:
>>
>>  2. Recharter in a way that will allow us to produce something like a
>>> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-**json.html<https://www.tbray.org/tmp/i-json.html>
>>> Produce something like that. Second victory!
>>>
>>
>> This is a fine trial balloon.  I have two comments:
>>
>
>  2) Stating the precision of numbers does not suffice: you ought also to
>> state explicitly that the valid range is numbers whose absolute value is
>> between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive.  For example,
>> the integer 4503599627370497 is not exactly representable as a double (it
>> is 2^52+1) and ought not to be allowed in I-JSON.  So I still prefer my
>> proposal of "is exactly representable as an IEEE 754:2008 64-bit binary
>> floating point number".
>>
>
> That doesn't work very well either, because you might need quite a few
> digits after the decimal point to *exactly* represent a binary fraction in
> decimal numbers. As an example, try to write something like
> (2**52+1) / 2.0**200 (** being exponentiation)
>
> You'll need something like 50+ digits, but nobody does this. What e.g.
> Ruby does (since about version 2.0) is to produce a representation that has
> just as many digits as necessary to unambiguously have a single closest
> representation in IEEE 754:2008.
>
> Regards,   Martin.
>
> ______________________________**_________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>