extend methods of decimal module

[Steven D'Aprano]

On Thu, 27 Feb 2014 15:00:45 -0800, Mark H. Harris wrote:

> Decimal does not keep  0.1  as a  floating point format (regardless of
> size) which is why banking can use Decimal without having to worry about
> the floating formatting issue...  in other words,  0.0 is not stored in
> Decimal as any kind of floating value...  its not rounded.... it really
> is   Decimal('0.1').

I'm sorry, but that is incorrect. Decimal is a floating point format, 
same as float. Decimal uses base 10, so it is a better fit for numbers we 
write out in base 10 like "0.12345", but otherwise it suffers from the 
same sort of floating point rounding issues as floats do.

py> a = Decimal("1.1e20")
py> b = Decimal("1.1e-20")
py> assert b != 0
py> a + b == a
True


In the case of 0.1 (I assume your "0.0" above was a typo), it is a 
floating point value. You can inspect the fields' values like this:

py> x = Decimal("0.1")
py> x.as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=-1)

There's a sequence of digits, and an exponent that tells you where the 
decimal point goes. That's practically the definition of "floating 
point". In Python 3.2 and older, you can even see those fields as non-
public attributes:

py> x._int
'1'
py> x._exp
-1

(In Python 3.3, the C implementation does not allow access to those 
attributes from Python.)

This is perhaps a better illustrated with a couple of other examples:


py> Decimal('1.2345').as_tuple()
DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-4)

py> Decimal('1234.5').as_tuple()
DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-1)


[...]
> The reason is that Decimal(.1) stores the erroneous float in the Decimal
> object including the float error for  .1    and   D(.1)  works correctly
>  because the D(.1) function in my dmath.py first converts the .1 to a
> string value before handing it to Decimal's constructor(s)

That *assumes* that when the user types 0.1 as a float value, they 
actually intend it to have the value of 1/10 rather than the exact value 
of 3602879701896397/36028797018963968. That's probably a safe bet, with a 
number like 0.1, typed as a literal.

But how about this number?

py> x = 3832879701896397/36028797218963967
py> Decimal(x)
Decimal('0.10638378180104603176747701809290447272360324859619140625')
py> Decimal(str(x))
Decimal('0.10638378180104603')

Are you *absolutely* sure that the user intended x to have the second 
value rather than the first? How do you know?

In other words, what you are doing is automatically truncating calculated 
floats at whatever string display format Python happens to use, 
regardless of the actual precision of the calculation. That happens to 
work okay with some values that the user types in by hand, like 0.1. But 
it is a disaster for *calculated* values.

Unfortunately, there is no way for your D function to say "only call str 
on the argument if it is a floating point literal typed by the user".

But what you can do is follow the lead of the decimal module, and leave 
the decision up to the user. The only safe way to avoid *guessing* what 
value the caller wanted is to leave the choice of truncating floats up to 
them. That's what the decimal module does, and it is the right decision. 
If the user passes a float directly, they should get *exact conversion*, 
because you have no way of knowing whether they actually wanted the float 
to be truncated or not. If they do want to truncate, they can pass it to 
string themselves, or supply a string literal.


-- 
Steven