139 lines
4.5 KiB
Plaintext
139 lines
4.5 KiB
Plaintext
PEP: 228
|
||
Title: Reworking Python's Numeric Model
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: pep@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum)
|
||
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 at the hardware level, that rationale does not
|
||
apply to Python. So, while it is acceptable to C programmers that
|
||
2/3 == 0, it is surprising to many Python programmers.
|
||
|
||
NOTE: in the light of recent discussions in the newsgroup, the
|
||
motivation in this PEP (and details) need to be extended.
|
||
|
||
|
||
Rationale
|
||
|
||
In usability studies, one of the least usable aspect of Python 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 model that might be easier to work with
|
||
can 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 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 true to a question from 1 to 5, will
|
||
also answer true to any following question. 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.
|
||
|
||
One consequence of these two rules is that all exact calcutions
|
||
are 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 number
|
||
and returns an inexact number which is a good approximation.
|
||
Inexact numbers must be as least as accurate as if they were
|
||
using IEEE-754.
|
||
|
||
Several of the classical Python functions will return exact numbers
|
||
even when given inexact numbers: e.g, int().
|
||
|
||
Coercion
|
||
|
||
The number type does not define nb_coerce
|
||
Any numeric operation slot, when receiving something other then PyNumber,
|
||
refuses to implement it.
|
||
|
||
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 are also
|
||
allowed to return an inexact result for an exact argument, and are
|
||
furthermore allowed to return a complex result for a real
|
||
argument.
|
||
|
||
|
||
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 operations? (probably, isnan/isinf should
|
||
be methods)
|
||
|
||
On 64-bit machines, comparisons between ints and floats may be
|
||
broken when the comparison involves conversion to float. Ditto
|
||
for comparisons between longs and floats. This can be dealt with
|
||
by avoiding the conversion to float. (Due to Andrew Koenig.)
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|