On Thu, Apr 7, 2022 at 2:51 PM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> 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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NKUUTXURMJXBWATMRIZULJR27U4MYDMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
