python-peps/pep-0228.txt

PEP: 228
Title: Reworking Python's Numeric Model
Version: $Revision$
Author: pep@zadka.site.co.il (Moshe Zadka)
Status: Draft
Type: Standards Track
Created: 4-Nov-2000
Post-History:

Abstract

    Today, Python's numerical model is similar to the C numeric model: 
    there are several unrelated numerical types, and when operations 
    between numerical types are requested, coercions happen. While the C 
    rational for the numerical model is that it is very similar to what
    happens on the hardware level, that rational does not apply to Python.
    So, while it is acceptable to C programmers that 2/3 == 0, it is very
    surprising to Python programmers.

Rationale

    In usability studies, one of Python hardest to learn features was
    the fact integer division returns the floor of the division. This
    makes it hard to program correctly, requiring casts to float() in
    various parts through the code. Python numerical model stems from
    C, while an easier numerical model would stem from 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 superficially non-suprising,
    it tends to have subtle gotchas. One of these is that printing numbers
    is very tricky, and requires correct rounding. In Perl, there is also
    a mode where all numbers are integers. This mode also has its share of
    problems, which arise from the fact that there is not even an approximate
    way of dividing numbers and getting meaningful answers.

Suggested Interface For Python Numerical Model

    While coercion rules will remain for add-on types and classes, the built
    in type system will have exactly one Python type -- a number. There
    are several things which can be considered "number methods":

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

    a. isexact()

    Obviously, a number which answers m as true, also answers m+k as true.
    If "isexact()" is not true, then any answer might be wrong. (But not
    horribly wrong: it's close the truth).

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

        If both operands satisfy isexact(), the result satisfies isexact()

        All field rules are true, except that for not-isexact() numbers,
        they might be only approximately true.      

    There is one important operation, inexact() which takes a number
    and returns an inexact number which is a good approximation.

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

Inexact Operations

    The functions in the "math" module will be allowed to return inexact
    results for exact values. However, they will never return a non-real
    number. The functions in the "cmath" module will return the correct
    mathematicl result.

Numerical Python Issues

    People using Numerical Python do that for high-performance
    vector operations. Therefore, NumPy should keep it's hardware
    based numeric model.

Unresolved Issues

    Which number literals will be exact, and which inexact?

    How do we deal with IEEE 754?

Copyright

    This document has been placed in the public domain.


Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: