python-peps/pep-0228.txt

111 lines
3.4 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

PEP: 228
Title: Reworking Python's Numeric Model
Version: $Revision$
Author: pep@zadka.site.co.il (Moshe Zadka)
Status: Draft
Type: Standards Track
Python-Version: ??
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 rationale for the numerical model is that it is very similar
to what happens on the hardware level, that rationale 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 features hardest to learn was
the fact that 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's 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-surprising, 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's 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 to 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 mathematical result.
Numerical Python Issues
People who use Numerical Python do so for high-performance vector
operations. Therefore, NumPy should keep its 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: