Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
What library to use for arbitrary precision decimals
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jeremy Shute <shutej@g...>
Subject: Re: [Caml-list] What library to use for arbitrary precision decimals
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...


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?

If you're keeping things in a database, you're going to be spending
milliseconds skipping across the disk for this and that -- what's the point
of placing an arbitrary limit on the size?  If the profiler shows that
you're eating cycles like candy, optimize your routine back down.


On 2/19/06, Brian Hurt <> wrote:
> On Sun, 19 Feb 2006, Joshua Smith wrote:
> > There are a couple of ways to handle money transactions without
> > rounding errors.
> >
> > You could use the Nums library, which provides arbitrary precision
> > calculations and numbers.   But even with arbitrary precision numbers,
> > you still can have the situation where you get 405.0345 which if this
> > were USD, you would still have to round if you wanted to pay someone
> > this amount.  You will still have the arbitrary precision this way,
> > however.
> >
> > The best way to handle money (in my experience) is to use integers.
> > Then you can define conversion functions but only have to convert it
> > to decimal for display purposes.  That way, even if you do a million
> > transactions you won't lose any information.   You can also handle
> > non-decimal based currencies/instruments/transactions that way[1]
> I agree with this recommendation.  The basic idea is that you use fixed
> point.  Say you want to be accurate to one thousandth of a cent (0.001
> cents).  You simply do all calculations in terms of millicents.  So the
> integer 1 represents one millicent.  One penny is represented as the
> integer 1,000- one thousand millicents.  The amount $2,345.67 is
> represented by the integer 234,567,000.
> 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.  This is larger than
> the world's GDP, so it should be large enough.  32 bits isn't enough- that
> only allows you to hold values up to $42,949.67.
> Brian
> _______________________________________________
> Caml-list mailing list. Subscription management:
> Archives:
> Beginner's list:
> Bug reports: