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?

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.

Jeremy



On 2/19/06, Brian Hurt <bhurt@spnz.org> 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:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>