111 lines
3.4 KiB
Plaintext
111 lines
3.4 KiB
Plaintext
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:
|