On Tue, Feb 19, 2013 at 5:03 AM, Benoit Chesneau <[email protected]> wrote: > On Tue, Feb 19, 2013 at 11:56 AM, Paul Davis > <[email protected]> wrote: >> Assuming this is the EDN spec thing: >> >> https://github.com/edn-format/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 > > 64-bit (double) precision is expected. > > floating-point-number > int M > int frac > int exp > int frac exp > int > digit > 1-9 digits > + digit > + 1-9 digits > - digit > - 1-9 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, IEEE-754) 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 IEEE-754 64bit double representation). This has ramifications and one of which is that encodings of those IEEE-754 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.
