From dev-return-9772-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Apr 25 05:43:13 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 74377 invoked from network); 25 Apr 2010 05:43:13 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 25 Apr 2010 05:43:13 -0000 Received: (qmail 64827 invoked by uid 500); 25 Apr 2010 05:43:13 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 64634 invoked by uid 500); 25 Apr 2010 05:43:12 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 64625 invoked by uid 99); 25 Apr 2010 05:43:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Apr 2010 05:43:12 +0000 X-ASF-Spam-Status: No, hits=-1343.5 required=10.0 tests=ALL_TRUSTED,AWL X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Apr 2010 05:43:10 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o3P5gn9d024106 for ; Sun, 25 Apr 2010 05:42:50 GMT Message-ID: <10375873.180921272174169918.JavaMail.jira@thor> Date: Sun, 25 Apr 2010 01:42:49 -0400 (EDT) From: "Thad Guidry (JIRA)" To: dev@couchdb.apache.org Subject: [jira] Commented: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly. In-Reply-To: <16644994.164731272043610077.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860657#action_12860657 ] Thad Guidry commented on COUCHDB-749: ------------------------------------- Researched at one time on http://www.programmersparadox.com/2008/02/05/erlang-integers/ February 6, 2008 @ 12:58 am Comment by Nic: Arbitrary-sized integer is nice but poorly supported in Erlang. If one only uses additions or multiplications its okay but integer power arithmetic operation is not supported. So it is untrue to say that Erlang can do integer arithmetic of arbitrary length integers. Even worse, it does not warns you when it produces a wrong answer. Try the following: 1> math:pow(2,55). 36028797018963970.0 Obviously no integral power of 2 can end by 0. All integral powers of 2 larger than 55 will give you a result ending by zero. This is because Erlang has not implemented an integer power function and relies on a float pow(x,y) function. This is why the result is a float. Actually it is an IEEE-754 float number in decimal64 format which means it has a maximum precision of 16 digits. Many applications dealing with large integers require true large integer arithmetic (including power), for example cryptology applications routinely do arithmetic modular power operations on very large integers. Though Erlang allows to write arbitrary large integers and do some basic operations it surely cannot be said to support arlitrary large integer arithmetic. For that, one can use mathematica (does arbitrary large float arithmetic as well) or specialized packages such as simod/modsim. > CouchDB does not persist large values of Numbers correctly. > ----------------------------------------------------------- > > Key: COUCHDB-749 > URL: https://issues.apache.org/jira/browse/COUCHDB-749 > Project: CouchDB > Issue Type: Bug > Affects Versions: 0.11 > Environment: All > Reporter: Jarrod Roberson > > All the following operations exhibit the same bug, large numbers don't get persisted correctly. They get something added to them for some reason. > 9223372036854775807 == java.lang.Long.MAX_VALUE > 1: go into Futon, create a new document and create a new field and enter the number 9223372036854775807, click the green check mark, the number changes to 9223372036854776000 even before you save it. > 2.curl -X PUT http://localhost:5984/test/longTest -d '{"value": 9223372036854775807}', the number gets persisted as 9223372036854776000 > trying to persist System.currentTimeMilliseconds() from java causes the same thing to happen occasionally. > This seems to be a pretty serious bug if I can't trust that my data is not being corrupted when submitted to the database. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.