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 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 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
> >>
> >>
>
>