Why not FP for Money?
jeff at ccvcorp.com
Wed Sep 22 02:43:32 CEST 2004
Michael Hobbs wrote:
>>What am I missing here?
>The end result is that you cannot use binary fractions to precisely
>represent decimal fractions. To represent decimal fractions in a binary
>system, you first need to shift the decimal point so that there is no more
>fraction and then work from there.
I believe that the O.P. understands this, but that it was his contention
that the imprecision can be finessed with proper rounding techniques.
While it's true that ten cents ($0.10) cannot be precisely represented
as a binary fraction (the round-trip imprecision yields
0.10000000000000001), the O.P. is of the opinion that, since any output
of an amount will involve throwing away all but a few of those
fractional digits, the imprecision error will almost certainly be
smaller than the amount of correction involved in rounding.
I believe, however, that the O.P. is mistaken. His premise is likely
true in the context of simple invoices and the like, where addition and
multiplication are the only operations needed. But consider, for
example, a program that calculates payments on a real estate mortgage.
Given that interest may need to be calculated on a daily basis, and that
the daily interest rate is a very small fraction, the imprecision of
floating point can then become much more significant relative to the
desired quantity. And given that there's a *lot* of calculations over
which this imprecision can build (a 30-year mortgage ~= 10957 days), and
the exponential nature of the interest calculation, this can become a
real issue. Especially when legalities require to-the-penny exactness.
It might conceivably be possible to figure out a rounding scheme that
would be equivalent to using fixed-point decimals, but I imagine that
creating such a scheme, and implementing it in every application that
does financial calculations, would be a lot more work than simply
writing and using fixed-point math.
More information about the Python-list