On 8/04/22 5:15 am, Christopher Barker wrote:
I actually have almost the opposite position -- variable precision is the most useful part of the Decimal type ;-)
So can you elaborate on how you use variable precision?
Note the docs again: "End users typically would not expect 1.1 + 2.2 to display as 3.3000000000000003 as it does with binary floating point." -- so it's really about the display, not the precision or accuracy of the result.
I don't think it's entirely about the display. It's also about things like sum([1/10] * 10) == 1 being False. 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.
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. I do agree, however, that you don't need *floating point* for this, and fixed point would probably be better. 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. :-) -- Greg