[Python-Dev] Adventures with Decimal

[Raymond Hettinger]

I sense a religious fervor about this so go ahead and do whatever you
want.

Please register my -1 for the following reasons:

a.) It re-introduces representation error into a module that worked so
hard to overcome that very problem.  The PEP explicitly promises that a
transformation from a literal involves no loss of information.
Likewise, it promises that "context just affects operations' results".

b.) It is inconsistent with the idea of having the input specify its own
precision:  http://www2.hursley.ibm.com/decimal/decifaq1.html#tzeros

c.) It is both untimely and unnecessary.  The module is functioning
according to its tests, the specification test suite, and the PEP.
Anthony should put his foot down as this is NOT a bugfix, it is a change
in concept.  The Context.create_decimal() method already provides a
standard conforming implementation of the to-number conversion.
http://www.python.org/peps/pep-0327.html#creating-from-context .

d.) I believe it will create more problems than it would solve.  If
needed, I can waste an afternoon coming up with examples.  Likewise, I
think it will make the module more difficult to use (esp. when
experimenting with the effect of results of changing precision).

e.) It does not eliminate the need to use the plus operation to force
rounding/truncation when switching precision.

f.) To be consistent, one would need to force all operation inputs to
have the context applied before their use.  The standard specifically
does not do this and allows for operation inputs to be of a different
precision than the current context (that is the reason for the plus
operation).

g.) It steers people in the wrong direction.  Increasing precision is
generally preferable to rounding or truncating explicit inputs.  I
included two Knuth examples in the docs to show the benefits of bumping
up precision when needed. 

h.) It complicates the heck out of storage, retrieval, and input.
Currently, decimal objects have a meaning independent of context.  With
the proposed change, the meaning becomes context dependent.

i.) After having been explicitly promised by the PEP, discussed on the
newsgroup and python-dev, and released to the public, a change of this
magnitude warrants a newsgroup announcement and a comment period.



A use case:
-----------
The first use case that comes to mind is in the math.toRadians()
function.  When originally posted, there was an objection that the
constant degToRad was imprecise to the last bit because it was expressed
as the ratio of two literals that compiler would have rounded, resulting
in a double rounding.

Link to rationale for the spec:
-------------------------------
http://www2.hursley.ibm.com/decimal/IEEE-cowlishaw-arith16.pdf
See the intro to section 4 which says:  The digits in decimal are not
significands; rather, the numbers are exact.  The arithmetic on those
numbers is also exact unless rounding to a given precision is specified.

Link to the discussion relating decimal design rationale to schoolbook
math
------------------------------------------------------------------------
---
I can't find this link.  If someone remembers, please post it.



Okay, I've said my piece.
Do what you will.



Raymond