Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of space.ship.traveller@gmail.com
 designates 74.125.83.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AF54484A-A8F8-4A39-A241-9F34672E9754@apache.org>
References: 
 <CAHkN8V8WaOf4nug0psqsx3G1awxfGsj+H1NeurRVeDu8NmbxDg@mail.gmail.com>
	<966B21E1-B4F8-42CF-A266-C562AA0D7E8E@apache.org>
	<CAHkN8V-brUnb=KLxbCVkT1tNJm3fr=4JZgnLACtDYaLuPWwLSw@mail.gmail.com>
	<AF54484A-A8F8-4A39-A241-9F34672E9754@apache.org>
Date: Tue, 17 Jul 2012 04:48:43 +1200
Message-ID: 
 <CAHkN8V_7ha1ibu3n0AcVBNKjuCWmN=fM+k+scGhpKqf_1sG74g@mail.gmail.com>
Subject: Re: Numerical accuracy and precision
From: Samuel Williams <space.ship.traveller@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b603b84e76b6e04c4f53331

--047d7b603b84e76b6e04c4f53331
Content-Type: text/plain; charset=ISO-8859-1

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 <rnewson@apache.org> 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 <rnewson@apache.org> 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
> >>
> >>
>
>

--047d7b603b84e76b6e04c4f53331--