This argument is entirely bogus. How do you represent $10/3 exactly in BCD? It's just as impossible as representing $0.10 in binary.

That is true, but irrelevant. You never make a transaction of $10/3, but you do make transactions of $.10. You can't have 3 1/3 dollars in your bank account. If you buy oranges 3/$1, one costs $.33, not $.33333. Two cost $.67. If you buy one today and come back for one tomorrow, they each cost $.33 -- you don't still owe the merchant an ephemeral third of a penny.

It doesn't matter, you argue? Well what happens with interest calculations? Suppose you need to add 5.7% per annum to a balance on a monthly basis. Are you going to do that precisely in BCD? Not a chance!

At every compounding period, you round the interest to the nearest penny. Something you can't do if the balance is represented as dollars in floating point.

Ultimately the only way to get decently accurate answers is to use enough extra digits of precision (and careful arrangement of calculation order) so that rounding errors are

My point, which you completely missed, is that financial calculations do not need extreme accuracy in the sense that scientists and engineers are used to. They need a specifically defined behavior which can only be accomplished through the use of integer or BCD arithmetic and correct coding.

insignificant. It ultimately makes no difference whether you do that in BCD or in binary. The results will be identical.

No, they wont.

For instance, this is what my (binary) calculator says about 200000 * (1 + 0.06/360)^(360*30): 1209748.03723

Unfortunately, that is wrong. Well, you have correctly calculated the given expression to the desired precision, but that is not the answer you get if you deposit $200,000 in a bank account with 6% interest compounded daily for 30 years of 360 days (!). The answer to that question would be the recurrence relation:

`x_0 = 200,000`

y_n = x_{n-1} * (0.06/360)

x_n = x_{n-1} + y_n

Where x_n is the balance on the nth day, and y_n is the interest payment on the nth day, which should be rounded to the penny. This is the only way that your balance (and the bank's balance which isn't shown) are legal values at the end of every day.

The end result is: $1,209,748.66 -- although I am still not 100% sure I got the rounding correct (round to nearest with ties going to the even number) since I was using integer arithmetic. You end up with a bit more than if you solve the the entire problem with high precision and then round at the end, because for the specific values chosen you happen to win a few more times than you lose on the rounded penny.