Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 51B3EE0AB for ; Wed, 20 Feb 2013 11:15:06 +0000 (UTC) Received: (qmail 25192 invoked by uid 500); 20 Feb 2013 11:15:04 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 24961 invoked by uid 500); 20 Feb 2013 11:15:04 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 24937 invoked by uid 99); 20 Feb 2013 11:15:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Feb 2013 11:15:04 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.216.178 as permitted sender) Received: from [209.85.216.178] (HELO mail-qc0-f178.google.com) (209.85.216.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Feb 2013 11:14:56 +0000 Received: by mail-qc0-f178.google.com with SMTP id j34so3032955qco.9 for ; Wed, 20 Feb 2013 03:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=9TkqaNK9LIBau/JEaCtydPykHXHc5HCL3FoWhgSUf5U=; b=uhff1my37wSxZFN25+RKch05A0FJqYUGJtTO3cUvbEUdwZMkrtLhxo9G0T0OBXqme8 aUP/uascYVroWE2ABoxnewlkH2EVAniwzwGlQaZuPNRKfbVu6Nrhsu/R6oRKMJcpTv7Z B7sDuKs+jCUI/cuxSi9W08BMwmPd/AyXKbPDZlI1NxfHBWb4RAhCAszl/GBSudHdou+m eGz88uOzooBcpuMsmS/qbmKDTPJgfsA7dAs7Bw8gE0xCZTcrEf8Iv3HNVO5ZF+zqALhy 2nBkJ2L/3RHHh+Brc+PD7jY/Oc70i1nA7kWNBQmcxna/qT2Ghjfex4BuT84tPHavzdo7 t79Q== MIME-Version: 1.0 X-Received: by 10.224.204.73 with SMTP id fl9mr289055qab.88.1361358875451; Wed, 20 Feb 2013 03:14:35 -0800 (PST) Received: by 10.49.64.232 with HTTP; Wed, 20 Feb 2013 03:14:35 -0800 (PST) In-Reply-To: References: <1CA1ECC0-5883-4714-9181-3E68B38FFAD6@couchbase.com> <1F01C9AF-B216-465B-AD02-3752908CEE40@sri.com> Date: Wed, 20 Feb 2013 12:14:35 +0100 Message-ID: Subject: Re: Fixed precision of floating point number not respected in views From: Benoit Chesneau To: "user@couchdb.apache.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Feb 20, 2013 at 11:33 AM, Robert Newson wrote: > I think we've said this every way it can be said now. > About the maths and the json limits probably. But maybe as a *data* storage we could offer a convenient way to maintain formats or data types when a uploading a doc. I mean even if you have stored -33.91017999999999688 in the db, if someone asking to have only 5 decimals then it will for sure become -33.91018 in most of the maths systems. In short i'm currently asking if the db should offer such facility (I find it interresting) of just let the app to do it. One good thing on forcing it in the db level is that all the clients that would access to this data will have the same result not depending on their own library: js> os =3D '{"a": -33.91018 }' "{\"a\": -33.91018 }" js> o =3D JSON.parse(os) ({a:-33.91018}) js> o.a -33.91018 >>> os =3D '{"a": -33.91018 }' >>> import json >>> o =3D json.loads(os) >>> o['a'] -33.91018 1> OS =3D << "{\"a\": -33.91018 } ">> 1> . <<"{\"a\": -33.91018 } ">> 2> jiffy:decode(OS). {[{<<"a">>,-33.91018}]} - beno=EEt