From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 79948BBBB for ; Sun, 19 Feb 2006 19:31:14 +0100 (CET) Received: from conn.mc.mpls.visi.com (conn.mc.mpls.visi.com [208.42.156.2]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1JIVDGp006016 for ; Sun, 19 Feb 2006 19:31:14 +0100 Received: from [192.168.42.2] (bhurt.dsl.visi.com [208.42.141.66]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id 31CC4811A; Sun, 19 Feb 2006 12:31:13 -0600 (CST) Date: Sun, 19 Feb 2006 12:31:38 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Jeremy Shute Cc: Joshua Smith , caml-list@yquem.inria.fr Subject: Re: [Caml-list] What library to use for arbitrary precision decimals In-Reply-To: <8c64de0a0602190921y557577f8pc3114e0bbeb1aa56@mail.gmail.com> Message-ID: References: <8c64de0a0602190921y557577f8pc3114e0bbeb1aa56@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 43F8B971.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 computations:01 penny:98 bcd:98 wrote:01 arbitrary:01 int:01 int:01 module:03 library:03 brian:04 brian:04 locale:04 needing:04 correctly:04 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=US_DOLLARS_3 autolearn=disabled version=3.0.3 On Sun, 19 Feb 2006, Jeremy Shute wrote: > If you use the Int64 module as the basis for your computations, you can > hold values up to $184,467,440,737,095.51 in size. > > How many Vietnamese Dongs is that? Some CIA factbook estimates of the GDP > of the world: > > $US 5.938e+13 > > One dollar will buy you a lot of Vietnamese Dongs: > > $VND 1.5838e+4 > > So, the GDP of the world (a popular number, to be sure) is about: > > $VND 9.4046e+17 > > ...and the the max signed int64 is around... > > 9.2234e+18 > > This is not an isolated case, there are quite a few currencies in the $? 10K > / $US 1 range. Point: you're one locale change and some depreciation away > from overflowing when someone wants to calculate a ratio for analysis. Why > not use a big int? You're right that if you're needing to calculate the World GDP, or even the American debt, you may need more bits. Although I was doing stuff in millipennies, simply doing stuff in centipennies still leaves you enough information to round to the nearest penny correctly, and gives you another order of magnitude headroom. The reason to use Int64 instead of Bigint is performance. This may or may not be an issue. Although I note that both Bigint and Int64 performance is going to way stomp BCD performance. Brian