On Tue, Feb 19, 2013 at 5:03 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Tue, Feb 19, 2013 at 11:56 AM, Paul Davis
> <paul.joseph.davis@gmail.com> wrote:
>> Assuming this is the EDN spec thing:
>>
>> https://github.com/ednformat/edn
>>
>> Then, no, this won't solve anything related to this discussion.
>
> It will somehow since you need to define the number expecation.
>
> floating point numbers
>
> 64bit (double) precision is expected.
>
> floatingpointnumber
> int M
> int frac
> int exp
> int frac exp
> int
> digit
> 19 digits
> + digit
> + 19 digits
>  digit
>  19 digits
> frac
> . digits
> exp
> ex digits
> digits
> digit
> digit digits
> ex
> e
> e+
> e
> E
> E+
> E
>
>
> So the spec force you to store the number in a format which isn't the
> case of JSON which slightly better and make sure that allows the
> library will get the same result.
>
>  benoit
"So the spec force you to store the number in a format which isn't the
case of JSON"
I'm not seeing that at all here. It says something about 64 bit
doubles being expected. Perhaps I'm reading that thing as an EBNF when
there's more to it?
Regardless of what the spec says, the basic operation of transforming
a number from an ascii representation into the a bounded size binary
representation (ie, IEEE754) in memory is a potentially lossy
operation. This is trivially proven by observing that a finite number
of bits cannot represent an infinite number of bits.
JSON does leave numerical details open to interpretation, though in
general the implementation details are consistent (ie, an IEEE754
64bit double representation). This has ramifications and one of which
is that encodings of those IEEE754 doubles don't necessarily look the
same as what we put in, even though we may expect as such given our
abstract concept of numbers.
