couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Tue, 14 Feb 2012 11:12:34 GMT
including bigdecimal.js in the next release would be very handy (and
fulfils one of my earliest tickets, COUCHDB-796).

Sorry for dropping out of the thread for a while there, having
connectivity issues at home. I'm now perched halfway up a mountain
holding a hand-crafted aerial towards the heavens; seems to be

The first time I encountered CouchDB's (or, strictly, SpiderMonkey's)
rather deficient number handling was quite sobering. I hear Paul's
concern that JSON doesn't define anything useful for numbers at all
(I'd argue that its specification is actually worse than useless). For
1.2.0, I'd be +1 on removing the obvious regression that %g
introduced. For 1.3.0, I'd love to see some formalization of how
CouchDB handles numbers (with an explicit promise to remain compatible
in future releases). I'd prefer a transparently lossless approach but
the edge cases might be too much to handle. After all, erlang
automatically handles big integers if you overflow but is also
silently converts integers to decimals if you're not careful.

Shorter Version: CouchDB should have first-class support for numerical
data, over and above the JSON spec.


On 14 February 2012 05:35, Paul Davis <> wrote:
> On Mon, Feb 13, 2012 at 7:23 PM, Jason Smith <> wrote:
>> On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis <> 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).
> I like this description and I agree completely. I only meant to
> illustrate that numbers pass through IEEE representations often enough
> that its not very safe to assume that numeric representations won't
> change.
>> 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 disagree heartily. Expecting every bit of internal code to remember
> that some JSON may or may not be partially parsed is about as
> unrelaxing as possible. Saying that JSON numbers that contain a
> decimal point or exponent are represented internally as IEEE-754
> double precision floating points is much more relaxing.
>> 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?
> Hypothetically I wouldn't reject it out of hand. Hypothetically, if
> something were to exist and were significantly less intrusive than a
> tagged binary then maybe. Though I hypothesize that nothing like this
> exists. Erlang's type system is basic and has no notion of operator
> overloading or otherwise. Thus, at best, we provide mathematical
> routines for internal use but nothing else changes much. It'd still be
> some sort of tagged value that we'd have to use function calls to do
> any sort of mathematical manipulation if the need were to arise.
> Also note that while JavaScript might be a PITA, its not the only view
> server and other view servers (specifically Erlang) will have to deal
> with this.
>>> 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,
>> 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.
> This approach is relaxing. If users need special number handling then
> they can use special number handling.

View raw message