Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 206.225.164.30 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Tue, 19 Feb 2013 09:33:31 -0800
Subject: Re: Fixed precision of floating point number not respected in views
Thread-Topic: Fixed precision of floating point number not respected in views
Thread-Index: Ac4Oxzh9Q7+GpB1VSKS+aoU2rouVFw==
Message-ID: <1CA1ECC0-5883-4714-9181-3E68B38FFAD6@couchbase.com>
References: <kfvbob$c6p$1@ger.gmane.org>	<kfvcjt$k97$1@ger.gmane.org>
 <CABvT1DFtvhBL7pbveHPK_b-cVsA++ria=MZBdw_GkjA4oMz2jQ@mail.gmail.com>
In-Reply-To: 
 <CABvT1DFtvhBL7pbveHPK_b-cVsA++ria=MZBdw_GkjA4oMz2jQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On Feb 19, 2013, at 1:09 AM, Robert Newson <rnewson@apache.org> wrote:

> If you want fixed precision, you'll need to store your numbers in
> strings and manipulate them that way too. A quick google in the past
> has shown a few "bignum" libraries for Javascript.

Another alternative, if you need a certain number of decimal digits of prec=
ision, is to premultiply the numbers by a fixed power of ten. For example, =
it looks like the OP may need five digits after the decimal point, so multi=
plying the input values by 10^5 would turn them into integers. Then the val=
ue 151.17281 would be stored as 15117281, which of course can be represente=
d precisely in 64-bit floating point.

(The limitation here is that since 64-bit doubles have a 56-bit mantissa (I=
IRC), the largest integer that can be represented precisely is about 10^16,=
 corresponding to a pre-scaled input value of 10^11.)

The obvious advantage over string encoding is that you can add, subtract an=
d compare numbers without having to do any conversion, and even if you do h=
ave to convert numbers (for multiplication, say) the conversion is very fas=
t compared to string<->number conversions.

As for alternative data formats, there are a lot of them around, and I don=
=92t see that EDN would have an advantage over any of the others that are b=
etter known and more widely adopted, like YAML. Changing away from JSON wou=
ld be a compatibility nightmare, anyway (speaking as the author of a Couch-=
compatible replication engine.)

=97Jens=