Why not FP for Money?

[Richard Hanson]

[Concerning Decimal's behavior re precision retention:]

Jeff Shannon wrote:

> Personally,  I think that it makes the most sense (i.e., will result in 
> the fewest surprises) if the greatest possible number of places is 
> preserved. 
>
> [snip the rest of Jeff's excellent comments and examples]

+1

I agree with Jeff. (Although, I'll allow that more discussion may shed
additional light on this issue.)

It seem to me that Decimal should not be conflated with, or restricted
to, the concept of "real-world measurements" wherein retention of only
partial precision may be warranted. These are orthogonal things. (I'm
not saying that such conflation is happening; I'm only adding my
thoughts on the subject.)

Note that even in the "measurements" problem-domain, error-analysis
gets *quite* tricky in complex trains of calculations such as
encountered in my field of land surveying, and more generally, in most
science and engineering calculations.[1] "Proving" how much precision
should be retained in real-world calculations involving "observations"
(as surveyors and geodesists call such) can be quite difficult if not
outright intractable. A common strategy is to make a best-guess
attempt at error-analysis (an approximate analysis, as it were), and
then retain more (sometimes much more) precision, and round after the
calculation train is finished.

And to reiterate this point: There may also be a need for exact
decimal numbers used in calculations not involving observations where
any truncation or rounding would represent an undesirable loss of
information and could lead to problems such as Jeff described -- as
well as other difficulties. 

I'm in favor of Decimal retaining the maximum precision (as specified
in the user's current Context) and then let the user round after the
calculation train is completed (using Context's ample ability for
such) as best as can be determined from the error analysis -- if such
analysis and rounding is appropriate. This would keep Decimal as
general as possible, and therefore, usable in the widest range of
use-cases.

For what it's worth, I also think the decision not to have a Decimal
constructor for floats is the right one -- for reasons related to
points in this post, and also, for reasons which others have already
explicitly pointed out.

(As to Decimal literals, I'm not finding a need for such in my COGO
sketches -- the normal constructors from strings or ints seems to work
fine for my use-cases. However, I can see that there may be some users
who find the current constructors slightly verbose[2] or "less
readable" -- more discussion may help determine the way forward re
this particular issue.)

(I also don't think that Decimal should be thought of as *only* a
"money" type; but this latter point already seems to be the
consensus.)


Richard Hanson
_______________________________________________
[1] The _HP-15C Advanced Functions Handbook_, (C) Hewlett-Packard
Company, 1982 has an excellent introduction to error-analysis in its
appendix "Accuracy of Numerical Calculations." More complete
discussions can be found in advanced surveying texts.

[2] A rather obvious simple reduction in typing can be realized by
using "from decimal import Decimal as D" which makes the constructor
from strings merely "D('8147307403831077403041.740817404170342')" for
example. (Sans my double-quotes, of course).

-- 
sick<PERI0D>old<P0INT>fart<PIE-DEC0-SYMB0L>newsguy<MARK>com