Hi Robert, Thanks for the clarification, I appreciate your prompt and detailed response.
The view server for Ruby seemed a bit "abandoned".. is any work being done on this? Kind regards, Samuel On 17 July 2012 04:28, Robert Newson <[email protected]> wrote: > 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 > >> > >> > >
