[Python-Dev] Revised decimal type PEP

[M.-A. Lemburg]

Guido van Rossum wrote:
> 
> > Also, why do you consider a float to be a "larger" value type than decimal?
> > Do you mean that a float is less precise?
> 
> (Warning: I think the following is a sound model, but I'm still
> practicing how to explain it right.)
> 
> I have this ordering of the types in mind:
> 
> int/long < decimal < rational < float < complex
> \---------------------------/   \-------------/
>             exact                  inexact
> 
> This is different from the Scheme numeric "tower" -- I no longer agree
> with the Scheme model any more.
> 
> The ordering is only to determine what happens on mixed arithmetic:
> the result has the rightmost type in the diagram (or a type further on
> the right in some cases).

Interesting. Here's what I use in mxNumber:

                     mx.Number.Float
                            ^
                            |
            --------> Python float
           |                ^
           |                |
           |         mx.Number.Rational
           |                ^
           |                |
     Python long --> mx.Number.Integer
           ^                ^
           |                |
            --------  Python integer
 
> The ints are a subset of the decimal numbers, and the decimal numbers
> (in this view) are a subset of the rational numbers.  Ints and
> decimals aren't closed under division -- the result of division on
> these (in general) is a rational.  While the exact values of floats
> are a subset of the rationals, the inexactness property (which I give
> all floats) makes that each float stands for an infinite set of
> numbers *including* the exact value.  When a binary operation involves
> an exact and an inexact operand, the result is inexact.
> 
> Tim's "numeric context" contains a bunch of flags controlling detailed
> behavior of numeric operations.  It could specify that mixing exact
> and inexact numbers is illegal, and that would be Michael's pedantic
> mode.  It could also specify warnings.  (I would never call a mode
> that issues warnings "safe" :-)

Could you perhaps write this coercion scheme up as informational
PEP ? I think it would help a lot as reference to what Python should
do and serve well for numeric extension writers as basis for their
coercion decisions.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/