# [Python-Dev] Revised decimal type PEP

Guido van Rossum guido@zope.com
Tue, 31 Jul 2001 19:26:13 -0400

```> 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).

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" :-)