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