Withdrawal

This PEP has been withdrawn in favor ofPEP 3141.

Abstract

Today, Python’s numerical model is similar to the C numeric model:there are several unrelated numerical types, and when operationsbetween numerical types are requested, coercions happen. Whilethe C rationale for the numerical model is that it is very similarto what happens at the hardware level, that rationale does notapply to Python. So, while it is acceptable to C programmers that2/3==0, it is surprising to many Python programmers.

NOTE: in the light of recent discussions in the newsgroup, themotivation in this PEP (and details) need to be extended.

Rationale

In usability studies, one of the least usable aspect of Python wasthe fact that integer division returns the floor of the division.This makes it hard to program correctly, requiring casts tofloat() in various parts through the code. Python’s numericalmodel stems from C, while a model that might be easier to work withcan be based on the mathematical understanding of numbers.

Other Numerical Models

Perl’s numerical model is that there is one type of numbers –floating point numbers. While it is consistent and superficiallynon-surprising, it tends to have subtle gotchas. One of these isthat printing numbers is very tricky, and requires correctrounding. In Perl, there is also a mode where all numbers areintegers. This mode also has its share of problems, which arisefrom the fact that there is not even an approximate way ofdividing numbers and getting meaningful answers.

Suggested Interface For Python’s Numerical Model

While coercion rules will remain for add-on types and classes, thebuilt in type system will have exactly one Python type – anumber. There are several things which can be considered “numbermethods”:

1. isnatural()
2. isintegral()
3. isrational()
4. isreal()
5. iscomplex()
6. isexact()

Obviously, a number which answers true to a question from 1 to 5, willalso answer true to any following question. Ifisexact() is not true,then any answer might be wrong.(But not horribly wrong: it’s close to the truth.)

Now, there is two thing the models promises for the field operations(+,-,/,*):

• If both operands satisfyisexact(), the result satisfiesisexact().
• All field rules are true, except that for not-isexact() numbers,they might be only approximately true.

One consequence of these two rules is that all exact calculationsare done as (complex) rationals: since the field laws must hold,then

(a/b)*b==a

must hold.

There is built-in function,inexact() which takes a numberand returns an inexact number which is a good approximation.Inexact numbers must be as least as accurate as if they wereusing IEEE-754.

Several of the classical Python functions will return exact numberseven when given inexact numbers: e.g,int().

Coercion

The number type does not definenb_coerceAny numeric operation slot, when receiving something other thenPyNumber,refuses to implement it.

Inexact Operations

The functions in themath module will be allowed to returninexact results for exact values. However, they will never returna non-real number. The functions in thecmath module are alsoallowed to return an inexact result for an exact argument, and arefurthermore allowed to return a complex result for a realargument.

Numerical Python Issues

People who use Numerical Python do so for high-performance vectoroperations. Therefore, NumPy should keep its hardware basednumeric model.

Unresolved Issues

Which number literals will be exact, and which inexact?

How do we deal with IEEE 754 operations? (probably, isnan/isinf shouldbe methods)

On 64-bit machines, comparisons between ints and floats may bebroken when the comparison involves conversion to float. Dittofor comparisons between longs and floats. This can be dealt withby avoiding the conversion to float. (Due to Andrew Koenig.)

Copyright

This document has been placed in the public domain.