Re: [Json] Limitations on number size?

[Nico Williams <[e-mail]>]

On Tue, Jul 9, 2013 at 4:24 PM, Peter F. Patel-Schneider
<[e-mail]> wrote:
> [Somewhat less facetious.]

I was surprised that needn't have been at all facetious.  JSON
surprises me all the time.  Since so many parsers have optional
behaviours, let's explore this path.

> Where does this end?   Do I have to worry about whether, for example, 0.0 is
> different from 0.00?   (Some people, e.g., numerical analysts, would argue
> that they are different - the first is 0+-0.05 and the second is 0+-0.005.)
> Do I have to worry about whether 0.1 is different from 1E-1?  (Some people,
> e.g., XML-philes, might argue that the first is a decimal and the second is
> a float or double.) Do I have to worry about whether 0 is different from 0.?
> (Some people, e.g., C programmers, might argue that 0 is an int and 0. is a
> float.)

I think unnecessary leading or trailing zeros, or even zero decimal
fraction, are fair game to lose.  Such things bear no information if
all we care about is numbers.  (.0 in some languages implies floating
point, as opposed to integer, but that's not relevant here.)  Ditto
negative zero.

Otherwise the tolerance level for information loss in numbers should
be specified by the application.  We can probably agree on some common
options that implementations *might* provide.  Here's all the options
that I think we should consider, but I'm probably missing some:

 - IEEE 754 {32, 64}-bit double with unspecified loss tolerance-- any
value that can be represented as such no matter what lossage, will be
accepted

 - IEEE 754 {32, 64}-bit double with no loss in exponent and with N
digits of precision, with some specified rounding

 - IEEE 754 {32, 64}-bit double with no loss (e.g., 0.1 can't be
parsed as a double exactly)

 - take the floor of the number as an integer of {32, 64, 128} bits

 - take the floor of the number as bigint (whatever that means for the
parser / host language) (subject to some arbitrary max size
constraint)

 - bignum with no loss (subject to some arbitrary max size constraint)