couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Klo <>
Subject Re: Fixed precision of floating point number not respected in views
Date Wed, 20 Feb 2013 08:37:39 GMT
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