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 precision).
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. B. On 20 February 2013 08:37, Jim Klo <[email protected]> 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" <[email protected]> wrote: > >> On Tue, Feb 19, 2013 at 6:33 PM, Jens Alfke <[email protected]> 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
