Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.210.180 as permitted sender)
References: 
 <CA+Y+444JKqhZvfZduqMmqaR1nCZU9Uvts_W9QCjxSfsnFdwmfA@mail.gmail.com>
 <CAN-3CBJDzfqgWc+Ouvdue8Xs+WO1b5ZCQrYBTZHRb3TPRGVkEw@mail.gmail.com>
 <CA+Y+444LOQ6=jYSKcmFZLH55xAOVfUd_m5V0xGuCeoTRLHmLag@mail.gmail.com>
 <CAN-3CBJ+tad3A5cjwKYTV9TkK=k5P35=nkaWfkNmhagZ8Cdnkw@mail.gmail.com>
 <CAAL6JQja5eXOkuqnWr2eT+kKHfufHyC2pFPp2TRiwjLjcJz-gA@mail.gmail.com>
 <CAAL6JQjhNWJTrX6s9xni=11-PP2V-3nmdA+1VDMjieLxarJWNQ@mail.gmail.com>
 <CAN-3CBJ0LGTc3gXGQc9Fa+2LKEqo4Q2fkOYvo1kNdGDSUu9hGQ@mail.gmail.com>
 <CAJNb-9pE6ZdiJ3Za6_uRXRWbH05p88QjUg5wxN6Vuc22nYt=CQ@mail.gmail.com>
 <CABvT1DGqPdKvytCTiNknwhuB7EotTbgHUR+cx2y0VEV0NUt-Cw@mail.gmail.com>
 <CAN-3CBK1A11vUzMXVKPxyuif3dBE6UW18=4Srd7Rwz30yKv0YQ@mail.gmail.com>
 <CAKmKYaCaMdmWvXy4HHjSoSo0Yiu-LsFTY+0cB5C+EJO8kf-g8Q@mail.gmail.com>
 <CABvT1DF0BMYmWnaA5wowkbjiODdOSxKOJrTv_3NDYtCaX85acw@mail.gmail.com>
 <CAN-3CBJzgdvar_p=Gao1VtXAu-kdJNwyq_s80+xiKTLiEwXQVw@mail.gmail.com>
 <CAKmKYaB=D6PNZRWVy1BSrYWTXZYMCq9GSjVMRP24z2ZokhD2pg@mail.gmail.com>
 <CAJNb-9oZP8v3LULoVEQ1ttfp6PZQB-fDuDM0fsYxE4BJGHr=MQ@mail.gmail.com>
 <CAN-3CBJRUYnJNtMxm-Bu2YLaADah3S1y1w_qNS=n4n6_iHaBrg@mail.gmail.com>
 <CAJNb-9osBa4Vm=+Qe+KvK3bftMf8RGYL80VP1kz9GYAT6ES4pw@mail.gmail.com>
 <CAN-3CBLgHpAz-rC5uC4KgP1_XDxcQsz3j3k=g7cD=BUgjqWv9Q@mail.gmail.com>
 <CAJNb-9rBJu69dJgq0Q2e=bKoPP4OgkhpeHyXBWoqn3pVJG2vmA@mail.gmail.com>
 <CA+Y+445Cu9s8pmUfpcHb+GOOqAAut-x=8+T9V_asDu-LvQxguQ@mail.gmail.com>
From: Robert Newson <robert.newson@gmail.com>
In-Reply-To: 
 <CA+Y+445Cu9s8pmUfpcHb+GOOqAAut-x=8+T9V_asDu-LvQxguQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 12 Feb 2012 17:30:57 +0000
Message-ID: <8171433147249007137@unknownmsgid>
Subject: Re: [VOTE] Apache CouchDB 1.2.0 release, first round
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm in favor of adding it to breaking changes and keeping the new
behaviour. Both ejson and jiffy use %g to encode numbers. This favors
a shorter encoding. On reflection, this is more desirable than
pretending that json distinguishes between ints and floats.

Sent from my iPhone

On 12 Feb 2012, at 16:49, Noah Slater <nslater@tumbolia.org> wrote:

> I've been over this before:
>
> http://code.google.com/p/simplejson/issues/detail?id=3D34
>
>
> From Bob Ippolito:
>
> Try alert(2.2000000000000002 =3D=3D 2.2) in ANY browser. It will say true=
.
>> JavaScript uses IEEE double for  Number, always has, always will.
>
>
> The general consensus seems to be that if you don't want JSON messing
> around with your numbers, then you encode them as strings. Otherwise,
> unless you're using integers, expect weirdness.
>
> However, I'm not sure I understand our choices here.
>
> Could someone explain the choices we have, with a summary of what the net
> result would be?
>
> On Sun, Feb 12, 2012 at 2:58 PM, Benoit Chesneau <bchesneau@gmail.com>wro=
te:
>
>> On Sun, Feb 12, 2012 at 3:03 PM, Jason Smith <jhs@iriscouch.com> wrote:
>>> tl;dr =3D Minor disagreement with Benoit but happy to go with his decis=
ion.
>>>
>>> On Sun, Feb 12, 2012 at 1:10 PM, Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>>>> On Sun, Feb 12, 2012 at 12:03 PM, Jason Smith <jhs@iriscouch.com>
>> wrote:
>>>>> On Sun, Feb 12, 2012 at 10:15 AM, Benoit Chesneau <bchesneau@gmail.co=
m>
>> wrote:
>>>>>> well as a database, CouchDB shouldn't change the way data are saved
>>>>>> in. I expect that the number I saved under the json type Number [1]
>>>>>> defined by the spec [2] is correctly saved and returned as is. No
>>>>>> roundtrip or precision lost should happen.
>>>>>
>>>>> Okay. "JSON type Number" is incoherent. JSON has only numerals, no
>>>>> numbers. JavaScript standards are as relevant as FORTRAN standards.
>>>>> But may we continue that discussion in JIRA?
>>>>>
>>>> I don't follow. JSON describes a number type, and refers to another
>>>> iso standard too. How it's incoherent.
>>>
>>> I could be wrong but I don't see a reference to an ISO or similar
>>> standard. I am reading RFC 4627.
>>>
>> The spec let me think that number should follow the ECMA-754 [1] . But
>> i will double check.
>>
>> Anyway for me a document is a data I post on the disc and it seems
>> reasonable to get the same result when I want to get it back.
>>
>> If it's not a regression, it isn't really a blocker I think. But I
>> think we should definitely fix it.
>>
>> - beno=EEt
>>
>> [1] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D4610935
>>