99 lines
3.3 KiB
Plaintext
99 lines
3.3 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
|
||
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:
|