And doesn't address indexes.
On Tue, Feb 19, 2013 at 7:51 AM, Volker Mische <[email protected]> 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 <[email protected]> >> wrote: >>> On 02/19/2013 10:13 AM, Paul Davis wrote: >>>> On Tue, Feb 19, 2013 at 3:09 AM, Robert Newson <[email protected]> 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 <[email protected]> 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 >>>>>> >>> >
