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 paul.joseph.davis@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51238F3D.5050605@gmail.com>
References: <kfvbob$c6p$1@ger.gmane.org> <kfvcjt$k97$1@ger.gmane.org>
 <CABvT1DFtvhBL7pbveHPK_b-cVsA++ria=MZBdw_GkjA4oMz2jQ@mail.gmail.com>
 <CAJ_m3YBwo0wzW5WGXmtinYPtxCvLH83mavXwcgSMq3sH_stzkg@mail.gmail.com>
 <51237473.8010601@gmail.com>
 <CAJ_m3YA+K_HPuDOGpgqEC-C2LKSr6pTbj6_rjbNwLYnfZpzy_Q@mail.gmail.com>
 <51238347.1090600@gmail.com>
 <CAJ_m3YAJ=LhuMb9oMtFUmBougz12GTV8AFaznEqZk=Tryg1beQ@mail.gmail.com>
 <51238F3D.5050605@gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Tue, 19 Feb 2013 09:14:36 -0600
Message-ID: 
 <CAJ_m3YC52pPPwFJn4_eOu1Ai-1V=E9VLGMZd0xP7irm3zi5GbA@mail.gmail.com>
Subject: Re: Fixed precision of floating point number not respected in views
To: Volker Mische <volker.mische@gmail.com>
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Possible. Given what I know of JS and its numbers I wouldn't be highly
optimistic that its not a mechanical turk.

On Tue, Feb 19, 2013 at 8:42 AM, Volker Mische <volker.mische@gmail.com> wrote:
> I think it does address indexes. Only the JavaScript engine will deal
> with the encoding/decoding. AFAIK SpiderMonkey/V8 doeas the right thing.
>
> Cheers,
>   Volker
>
> On 02/19/2013 02:53 PM, Paul Davis wrote:
>> And doesn't address indexes.
>>
>> On Tue, Feb 19, 2013 at 7:51 AM, Volker Mische <volker.mische@gmail.com> wrote:
>>> Or we stop converting the document body into Erlang and store them as
>>> raw JSON strings, so that there is no Erlang<->JSON conversion going on.
>>> I know that's a big change.
>>>
>>> Cheers,
>>>   Volker
>>>
>>> On 02/19/2013 01:57 PM, Paul Davis wrote:
>>>> It used mochijson2 which uses mochinum.erl which uses arbitrary
>>>> precision arithmetic which makes this a lot easier (IIRC, its the
>>>> ability to raise numbers to arbitrarily large powers).
>>>>
>>>> I do agree the behavior would be nice if it could be provided but the
>>>> runtime cost is prohibitive if implemented in Erlang (arbitrary
>>>> precision arithmetic is also generally slower than FPU operations).
>>>>
>>>> Also, so we're being more specific, it returned numbers with the
>>>> fewest number of digits required that could then be fed into a
>>>> standard libc parsing algorithm to return the same floating point
>>>> representation based on what's in RAM. There are other assumptions and
>>>> caveats related to the various thingers as well.
>>>>
>>>> On Tue, Feb 19, 2013 at 6:47 AM, Volker Mische <volker.mische@gmail.com> wrote:
>>>>> On 02/19/2013 10:13 AM, Paul Davis wrote:
>>>>>> On Tue, Feb 19, 2013 at 3:09 AM, Robert Newson <rnewson@apache.org> wrote:
>>>>>>> "I have stored fixed precision numbers in a database". You haven't,
>>>>>>> unfortunately, because you can't. Javascript only has one kind of
>>>>>>> number, 64-bit floating point.
>>>>>>>
>>>>>>
>>>>>> Its a tidge more complicated than that. Its actually a combination of
>>>>>> the Erlang JSON decoder/encoder roundtrip plus the JavaScript decoder.
>>>>>
>>>>> I remember that older version of Apache CouchDB (IIRC 1.1) did return
>>>>> the numbers as they were put it. Don't know which decoder was used back
>>>>> then.
>>>>>
>>>>> I'd love to see this behaviour coming back.
>>>>>
>>>>> Cheers,
>>>>>   Volker
>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> Though the end result is the same. If you need fixed precision
>>>>>> numbers, then using JSON's syntax for "numbers with decimal points and
>>>>>> non-zero digits after the decimal point" will lead to surprising
>>>>>> results and lack of fidelity.
>>>>>>
>>>>>> I've had a few discussions on this for Jiffy in terms of round
>>>>>> tripping something as trivial as 1.1 through a JSON decoder/encoder
>>>>>> pair. Turns out this is really really hard.
>>>>>>
>>>>>> Here's the Python ticket where they added it to the language for a
>>>>>> good discussion on the details required to make this actually work:
>>>>>>
>>>>>> http://bugs.python.org/issue1580
>>>>>>
>>>>>>> B.
>>>>>>>
>>>>>>> On 19 February 2013 08:20, Luca Morandini <lmorandini@ieee.org> wrote:
>>>>>>>> On 02/19/2013 07:05 PM, Luca Morandini wrote:
>>>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> I have stored fixed precision numbers in a database, but when they are
>>>>>>>>> spit out by
>>>>>>>>> a view, the precision is full, and -which is worse- the trailing decimal
>>>>>>>>> digits
>>>>>>>>> are not all zeroes.
>>>>>>>>
>>>>>>>>
>>>>>>>> In the CouchDB: The Definitive Guide", I have found out that "most clients"
>>>>>>>> would interpret, say, 15.7 as 15.69999999999 (or so), which I suppose is
>>>>>>>> exactly what I observed... but what is meant as "client" in this context, a
>>>>>>>> view engine ?
>>>>>>>>
>>>>>>>> Anyway, any view to tune this feature of the JavaScript view engine ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Luca Morandini
>>>>>>>> Data Architect - AURIN project
>>>>>>>> Department of Computing and Information Systems
>>>>>>>> University of Melbourne
>>>>>>>> Tel. +61 03 903 58 380
>>>>>>>> Skype: lmorandini
>>>>>>>>
>>>>>
>>>
>