Why not FP for Money?
newsgroups at jhrothjr.com
Thu Sep 23 14:37:24 CEST 2004
"Chris Barker" <Barkmann at gmail.com> wrote in message
news:cc887c1d.0409222103.388c40de at posting.google.com...
> "Batista, Facundo" <FBatista at uniFON.com.ar> wrote in message
>> Well, actually that's an issue, because the "banker's rounding" is not
>> same rounding in every country.
>> That's why in Decimal you have a lot of roundings to choose.
> Exactly. I am the OP, and my question was "What am I missing?", and
> that is the above is the answer.
Just a couple of points.
> Floating point arithmetic is useful for continuous quantities,
> or quantities that are measured (as in weighed, etc.) Integers
> (and rationals) are useful for things that are counted, which
> includes currency units, but also includes anything else that
> comes in discrete units (apples and oranges, for instance).
> That only applies until you start slicing the oranges, and only
> applies here if you are dealing with actual pennies. When people
> calculate interest, tax, etc, they want to deal in fractional pennies.
> That's why we can't just use integer pennies and have done with it.
> However, it is true that while fractions do need to be dealt with, the
> should not "float". That being said, as someone mentioned, accounting
> practices are not neccsarily logical. Personally, thinking of money it
> terms of significant digits would be fine with me. Is there really any
> point in keeping track of the pennies when talkin gof trillions of
This one was mine. There are a couple of points here in your
First, there's a convention that avoids all of the trouble with
incremental rounding. I've seen it used in a number of places,
of which calculating withholding tax for US tax returns is
probably the most accessable.
The tax pamphlets give you a number of ways of doing this,
but real payroll programs all do it one way: calculate the
year to date tax, subtract the year to date withholding,
and withhold the difference. This way you will always
come out exactly even at the end of the year, without
having to worry about rounding. (There are other issues
in the US tax code that make it effectively impossible to
come out with the right amount of tax - measured by
the taxpayer's return - but those are not relevant here.)
This answer also applies to several other connundrums
later that I won't reply to.
The last sentence confuses finance with accounting.
In financial calculations, it is perfectly adequate to
ignore insignificant amounts. In bookkeeping, it
> One interesting distiction here: binary vs. decimal and floating point
> vs. fixed point are orthoganal concepts that have been mingled here.
> Alex pointed out that decimal floating point has the same problems as
> binary as far as accuracy is concerned.
> What we'd _really_ want to specify is 'keep exactly two digits AFTER
> decimal point, no matter how many there are BEFORE', but that's not
> decimal's job -- it's still a floating point type, albeit decimal, NOT
> fixed-point one. Maybe we do need a fixed-point-decimal for 2.5...?
> Or a currency type, specifically.
Well, this was discussed and rejected - see the discussion
on the decimal floating point PEP. I disagree with the
> thanks everyone, for some enlightening discussion.
More information about the Python-list