Here's a draft PEP.
Have I already mentioned how much it irks me to cater for other
editors in the PEP text itself?
PEP: Unassigned
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.
Copyright
This document has been placed in the public domain.
Local Variables:
mode: indented-text
indent-tabs-mode: nil
End:
--
Moshe Zadka <sig@zadka.site.co.il>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4