Re: [Json] Limitations on number size?

["Peter F. Patel-Schneider" <[e-mail]>]

My reasoning is more like:

I was trying to find the answer to Y about X in the defining document for X 
and the only thing related to Y there (or related to Y in anything pointed to 
from there) was Z so Z should be the answer.

Yes, this isn't quite the situation, but it's close.

Yes, this isn't the way things should work in a defining document, but that's 
the situation with respect to this defining document.

Peter F. Patel-Schneider



On 07/09/2013 06:12 PM, Tatu Saloranta wrote:
> On Tue, Jul 9, 2013 at 3:58 PM, Peter F. Patel-Schneider 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Where then am I supposed to go to find out what a JSON number
>     represents?   There are many possibilities (float only, rational only,
>     separate integer and float, separate rational and float,
>     variable-precision decimal only, separate integer and variable-precision
>     decimal, variable precision float only, ...). And then there are the
>     various range possibilities.
>
>     The only suitable guidance provided in RFC4627 is via ECMAScript and
>     ECMAScript is firmly IEEE floating point double only.
>
>     So why are you surprised that I came up with this conclusion?
>
>
> So your proof is of the form "I was trying to find answer to X; and the only 
> answer I found was Y; thereby it MUST BE the right answer"? That is a 
> logical fallacy of some kind.
>
> But you are right in that perhaps I should not be surprised. Different 
> people reach different conclusions all the time, even if given same information.
>
> -+ Tatu +-
>
>     peter
>
>
>
>
>     On 07/09/2013 02:34 PM, Tatu Saloranta wrote:
>
>         I am surprised you came to this conclusion, since I assumed we were
>         finally getting rid of misconception that JSON is closely tied to
>         Javascript.
>
>         This is not to say that the way JSON (under-)defines numbers is
>         optimal; but at this point forcing castrated version of numbers --
>         which would lead to practical problems like preventing use of 64-bit
>         longs for timestamps -- would be counter-productive and to me a
>         non-starter.
>
>         -+ Tatu +-
>
>
>
>