I don't think it's entirely about the display. It's also about
things like sum([1/10] * 10) == 1 being False.
sure, but:
In [18]: sum([Decimal(1) / Decimal(3)] * 3) == Decimal(1)
Out[18]: False
Which is just as bad -- not as "confusing" to folks that are used to decimal, but I get a bad feeling when the docs talk about "exact" -- I'm not sure that the distinction that's it's only *decimal* fractions that are exact comes through for more casual readers.
This is where
"human-friendly" display actually makes things worse, because
repr() makes it *look* like 1/10 equals decimal 1.0, but it really
doesn't.
well, yes, that is a good point.
> Calculating interest, inflation, who knows what could easily
> introduce non-exactly-representable-in-decimal numbers.
Yes, but when it comes to the point of e.g. adding some interest
to an account, the amount of interest needs to be an exact
multiple of 0.01 dollars. And if you add up all the interest
transferred during your nightly run, it had better exactly
equal the amount taken out of the account the interest is being
paid from.
Sure -- but that requires careful rounding and all that -- I don't think Decimal makes that any easier, frankly, particularly if you use cents as your units, rather than dollars.
(though my earlier point that Decimal does allow you to control the rounding is an important feature for these types of applications)
BTW, there's an accounting package I work with that uses binary
floating point for money, and seems to get away with it. Probably
because everything that goes into the database gets rounded to
a defined number of decimal places, so errors don't get a chance
to accumulate to the point where they would cause a problem.
It does make me a bit nervous, though. :-)
Well -- the authors of that package seem to have demonstrated my point -- you need to take care with rounding and limited precision regardless -- and once you do that, binary is just as good :-)
Are you sure you can trust it though? There's the old urban legend about the programmer for a bank writing the code so that the rounded pennies would go into his account -- it added up to a lot of money that nobody noticed was missing. The legend goes that he was only caught because the bank had a promotional event in which they drew a randomly selected account -- and found his.
Are you SURE your accounting software is doing the right thing? ;-)
-CHB
Also -- if it uses 64 bit floats, it'll have problems with trillions of dollars :-) -- might lose track of some cents there ....
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython