incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Fixed precision of floating point number not respected in views
Date Wed, 20 Feb 2013 10:33:57 GMT
The transport protocol or storage format is not the issue here,
though. If you're simply displaying this value, then the suggestion to
use strings should not be controversial. The only reason to care this
much about numeric representation is so you can do math. As several
folks have noted, if you're using floating point for handling money
values, you are in a state of sin already. For many other
applications, 64-bit fp math is pretty good. Your problem domain
should tell you whether you require specific behavior from your
numeric data types (like specific rounding algorithms, or arbitrary

Simply put, a value like 0.3 cannot be represented in a floating point
value. Before the binary point, each position goes 1, 2, 4, 8, etc.
After the binary point it's 1/2, 1/4, 1/8, etc. This is with 1.5 can
roundtrip correctly and why 0.3 cannot (at least, not with a finite
number of binary points).

I think we've said this every way it can be said now.


On 20 February 2013 08:37, Jim Klo <> wrote:
> I'm not sure if this is a terrible idea or not... (As I've never tried it, but got the
idea while following this thread) But how about encoding with protocol buffers when storing
into couch... There are a few protocol buffers JS libraries that could be used to marshall
values within MapReduce, list, show, and other functions... but then you possibly run up against
spidermonkeys precision issues, at least there would be no Erlang to Spidermonkey round trip
issues. With the amount of data you seem to be concerned about, it might even help with space,
especially if you made list/show functions that streamed in protobufs. Just not sure how viable
or practical it would be.
> I know I've run into this issue before and have conceded to store FP as an array of 2
int values (mantissa and exponent) as well as encoded with strings. However I've not needed
to do any Maths within CouchDB, just pure storage.
> Sent from my iPhone
> On Feb 20, 2013, at 12:03 AM, "Benoit Chesneau" <> wrote:
>> On Tue, Feb 19, 2013 at 6:33 PM, Jens Alfke <> wrote:
>>> As for alternative data formats, there are a lot of them around, and I don’t
see that EDN would have an advantage over any of the others that are better known and more
widely adopted, like YAML. Changing away from JSON would be a compatibility nightmare, anyway
(speaking as the author of a Couch-compatible replication engine.)
>> edn has the advantage to provide you a way to describe the number by
>> annotating it somehow. So it doesn't  solve the "maths" problem but
>> would solve the representation or at least make it a little better
>> when for example you expect a real with 2 decimals  you will get it
>> instead of having X non expected decimals.
>> Going to a new format would be for sure a challenge but not that big
>> if apache couchdb and compatible product respect the content-type
>> header. And it will be a user choice.
>> - benoît

View raw message