Kristian Nielsen wrote:
Jim Starkey <[email protected]> writes:
But as I have mentioned before, dropping into arbitrary precision
binary to handle currency is really foolish. A 64 bit int can hold a
lot of dollars and cents and is a hell of a lot faster than arbitrary
Yes, 64-bit ints holding centi-cents sounds quite good for currency, 18 digits
of precision (19 for insigned).
(And a $200 CPU can do 30 billion 64-bit additions/subtractions per second.)
I once attended a talk from someone who developed a system that handles
pension funds for every person in Sweden. Their problem was with the
application language (which was Perl), which does not have any native 64-bit
integer (they ended up working with some bignum package).
Now that I think it over, I do not remeber seeing a 64-bit integer type in any
high-level application language. Perl does not have it, Javascript does not. I
think Java used to not have it, maybe it's been included in Java/.NET by
now. I don't think PHP has it either, not sure about PHP/Python?
Java was born with a a 64 bit integer type, long.
I've had this discussion a number of times. The first was with the
Rdb/VMS group in 1982 (they had the same objections to decimal scale
factors on binary numbers, but they got over it). At the time, a 64 bit
integer was big enough to express the US national debt in milli-lire.
Unfortunately, since then, the US national debt has gotten larger and
the lire smaller, so this is no longer true. I believe it is still
possible to expression the US national debt in fraction lire, however.
About the only time that binary > 64 bits is required for currency is to
handle fields declared as numeric(24,12) in dbt2/tpcc. Like most things
in database benchmarks, they have no analog in real life.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
