[Python-Dev] Mixing float and Decimal -- thread reboot

[Raymond Hettinger]

>> 
>> Note that this would involve adding mixed Fraction/Decimal arithmetic as
>> well as Decimal/float arithmetic.
> 
> Yes, that was my intention too.

+1


> 
>> I placed Decimal to the left of
>> Fraction to keep Decimal's dependencies clear and because Decimal ->
>> Fraction conversions appear straightforward (using power of 10
>> denominators) without introducing the precision issues that would arise
>> in Decimal -> Fraction conversions.
> 
> This is just wrong. Decimal is much more like float than like int or
> Fraction, due to its rounding behavior. (You cannot produce exact
> results for 1/3 using either Decimal or float.)


Right.  We should be guided by:

    fractions are a superset of decimals which are a superset of binary floats.

And by:

    binary floats and decimal floats both implement all of the operations
    for the Real abstract base class.

> 
> Yes, this is what I was trying to say (but didn't find the right words for).
> 
>> So "quick and dirty don't need a perfect answer" operations end up with
>> ordinary binary floats, while more precise code can enable the signal
>> trap to ensure the calculation fails noisily if binary floats are
>> introduced.
> 
> But does this break a tie for the relative ordering of Decimal and
> float in the tower?
> 

It seems to me that Decimals and floats should be considered at
the same level (i.e. both implement Real).

Mixed Decimal and float should coerce to Decimal because it can be
done losslessly.

There is no need to embed a notion of "imperfect answer".
Numbers themselves are exact and many mixed operations
can be exact is the coercions go the right way.

Some folks who have had bad experiences with representation
error (i.e. 1.1 cannot be exactly represented as a binary float) or
with round-off error (i.e. 1.0 / 7.0 must be rounded) tend to think
of both binary or decimal floats as necessarily inexact.  But that
is not the case, exact accounting work is perfectly feasable
with decimals.  Remember, the notion of inexactness is a taint,
not an intrinsic property of a type.  Even the Scheme numeric
tower recognizes this.  LIkewise, the decimal specification also
spells-out this notion as basic to its design.


> 
>> Whatever we decide to do will need to be codified in a PEP though.
>> "Cleaning Up Python's Numeric Tower" or something along those lines.
> 
> The cleanup is really just specific to Decimal -- int, Fraction and
> float are already properly embedded in the tower (PEP 3141 doesn't
> advertise Fraction enough, since it predates it). That we may have to
> change the __hash__ implementation for the other types is merely a
> compromise towards efficiency.

I believe that no "clean-up" is necessary.  Decimal already implements
the Real ABC.   All that is necessary is the common __hash__ algorithm
and removing the restriction between decimal/float interaction so that
any two instances of Real can interoperate with one another.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100321/b5740c93/attachment.html>