On 02/20/2013 05:29 PM, Jens Alfke wrote:
On Feb 19, 2013, at 7:58 PM, Luca Morandini
<[email protected]> wrote:
Well, it is not a matter of precision -as it may be enough for most purposes-
but of external representation: every user would expect to get back the same
data he had put into the database.
But you _can’t_ put a number like 0.1 into a binary floating-point value; only
a very close approximation of it. It’s a mathematical impossibility, because
0.1 has an infinite number of digits in binary. So round-trip fidelity is
impossible. The only way to store a number like that exactly is to represent it
as BCD or fixed-point or as a string. (It seems weird to be explaining this to
someone with an IEEE email address…)
Well, let me repeat it for -I guess- the 3rd time: the issue is the
representation, which is worsened by the absence of different number types in JSON
and the lack of pretty-printing (in the words of Paul Davis) in CouchDB.
After all the explanations on this thread, I have now a better understanding on
why this happens... but it remains an issue.
It sounds like you are just going to have to accept tiny bits of roundoff
error. If you think it makes the numbers look ugly, make your app do a bit of
truncation when it displays them. It seems like hyperbole to say that this is
going to block your project.
The sore point is -repeating myself again- that the non-rounding of output makes
number-heavy JSON rather cumbersome, and when you have to transfer thousands of
points to the client, every digit counts.
Regards,
Luca Morandini
Data Architect - AURIN project
Department of Computing and Information Systems
University of Melbourne
Tel. +61 03 903 58 380
Skype: lmorandini
