Re: [Json] Limitations on number size?

[Stephan Beal <[e-mail]>]

On Wed, Jul 10, 2013 at 12:07 PM, Peter F. Patel-Schneider <
[e-mail]> wrote:

> Relatively is one of these weasel words that we all use.


Agreed.



>
> However, the working group mailing archives contain evidence that there
> are indeed significant problems when using JSON to portably interchange
> data, particularly  binary data.


Such cases are their own fault: JSON never, every claimed to be able to
support binary data. Wrong tool for the job, period.


> Implementors tend to use whatever default limits the platform provides
> (e.g. 32-bit on 32-bit platforms and 64 on 64-bit, and 6-digit precision in
> doubles seems to be conventional in C libraries).
>
>> People using high-precision/very large/very small numbers are certainly
>> aware of the limitations/portability problems, and will (possibly after
>> falling on their face with JSON) pick a different format.
>>
>
> Are they really aware of all the potential problems?   And just what
> counts as high-precision/very large/very small?  Does 0. belong to any of
> these categories?


Excellent point - no, they are most certainly not aware of all potential
problems, and that's why they rely on the system-level defaults - because
they know that very smart people have spent time implementing them and
making sure they are reasonable for a wide variety of use cases. Least
common denominator. It would be impossible to expect every JSON parser
implementor to understand the intricacies of binary encodings of floating
point values. (i've implement 3 or 4 JSON parsers in C and C++ and have
never read any of the relevant IEEE docs - i rely on the system to define
my legal ranges).


>> Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers
>> are JavaScript, and JS doesn't differentiate between doubles and integers,
>> so 0 is, in effect equivalent to 0.0. In fact, there are few real-world
>> applications using JSON where the two are _not_ equivalent (barring
>> scientific, high-precision, math-centric apps, of course, and those should
>> probably be looking for a different format which guarantees them their
>> desired ranges/limits).
>>
>
> I would appreciate some evidence to back up the claim that the vast, vast
> majority of JSON is handled in an environment where the JSON numbers 0 and
> 0.0 do indeed represent the same thing.


You're right, and i'll see if i can find some properly collected
statistics. My "evidence" is purely anecdotal - 90+% of the applications i
work with which use JSON are www-based or www-bound.

The RDF W3C workiing group is in the last stages of putting its stamp of
> approval on JSON-LD, which presents the JSON numbers 0 and 0.0 to RDF as
> being different.
>

Different standard - doesn't interest me ;). i don't have a single
application where the difference between 0 and 0.0 is relevant to the
outcome of a calculation (with the minor exception of maybe output
formatting).

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal