The built-in reduce functions are executed in erlang, which has arbitrary precision for integers and 64-bit precision for floating point.
The JSON standard is notoriously poor around numbers but couchdb does as straight a translation as possible. The maximum integer possible in javascript without rounding is 2^53 (9,007,199,254,740,992). This is a fair multiple of the world's GDP, for context. I haven't seen a recommendation for a big integer library and there's a jira ticket (that I raised) to include arbitrary precision math in couchdb as standard. There are view servers available for both Python and Ruby. B. On 16 Jul 2012, at 16:33, Samuel Williams wrote: > Well, I'm using a big integer library for accounting in Ruby, but I'm not > sure how to do map-reduce with JavaScript without potentially corrupting > values... what is the recommended approach? > > Also, what is the precision of _sum and other builtin reductions? > > Is there a recommended big integer library for use with the > JavaScript/SpiderMonkey interpreter and is this documented anywhere? With > the natural JSON format, I assume there are no limitations to integer size, > but clearly JSON -> JavaScript object will impose some data type > limitations... it seems like a language with built in support for big > integers would be ideal, e.g. Python, Ruby, rather than JavaScript. > > Kind regards, > Samuel > > On 17 July 2012 02:27, Robert Newson <[email protected]> wrote: > >> >> Correct, numeric precision using the javascript view engine is limited to >> the 64-bit floating point numbers that spidermonkey supports. >> >> For arbitrary precision math, encode your values as strings and use a >> bignum library. >> >> As an aside, if you're using floating-point numbers in an accounting >> context, you have already fallen into sin. >> >> B. >> >> On 16 Jul 2012, at 15:01, Samuel Williams wrote: >> >>> Hi, >>> >>> I'm wondering, when using the JavaScript backend, is the numerical >> accuracy >>> limited to that of JavaScript? >>> >>> How can we implement a numerically correct sum function, e.g. using a big >>> integer implementation? >>> >>> Kind regards, >>> Samuel >> >>
