On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <[email protected]> wrote: > The issue here is how we define "same". Given your examples you appear > to be arguing for byte level equivalence between input and output. > While this may seem quite logical and even perhaps a necessity for > something that calls itself a datastore, its not how the world works. > Rather than convince you, I'll just show two examples:
Hi, Paul. I hope you'll agree that just because SQL does that, CouchDB doesn't necessarily have to. Of course, you make a strong case that Couch can do what most people expect (round trip the sequence of numerals through IEEE floats). FWIW, I started out by taking a similar position as yours; however, I feel the users and Filipe are describing a more relaxing Couch. I notice you didn't like Filipe's patch; but what if CouchDB used a hypothetical decimal implementation? It had honest-to-God proper numbers, with round-trip identity and all of it? (View collation is a distraction since that is Javascript and we can all expect IEEE-754.) In other words, instead of an experimental encoding trick, CouchDB used well-known decimal types. Would that change your opinion at all? > I'd try MySQL but I bet it returns 2.89 because of some bug. Hey, come on, that's bigotry. > In the end, as we've constantly repeated, anyone that wants the > absolute best numerical fidelity when using JSON should always use > strings and rely on application logic to ensure that a suitable > bignum/bigdecimal implementation exists. CouchDB has one already, https://github.com/iriscouch/bigdecimal.js I used GWT to compile the Apache Harmony (Java) BigDecimal implementation to Javascript, and wrap it in CommonJS. It works in CouchDB, Node.js, and browsers. -- Iris Couch
