Added first revision of numerical model pep.

pep-0000.txt

@@ -119,6 +119,7 @@ Numerical Index
  SD  225  pep-0225.txt  Elementwise/Objectwise Operators       Zhu, Lielens
  I   226  pep-0226.txt  Python 2.1 Release Schedule            Hylton
  S   227  pep-0227.txt  Statically Nested Scopes               Hylton
+ S   228  pep-0228.txt  Reworking Python's Numeric Model       Zadka
 
 
 Key

pep-0228.txt

@@ -0,0 +1,112 @@
+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.
+
+    6. Rationale -- The rationale fleshes out the specification by
+       describing what motivated the design and why particular design
+       decisions were made.  It should describe alternate designs that
+       were considered and related work, e.g. how the feature is
+       supported in other languages.
+
+       The rationale should provide evidence of consensus within the
+       community and discuss important objections or concerns raised
+       during discussion.
+
+    7. Reference Implementation -- The reference implementation must
+       be completed before any PEP is given status 'final,' but it
+       need not be completed before the PEP is accepted.  It is better
+       to finish the specification and rationale first and reach
+       consensus on it before writing code.
+
+       The final implementation must include test code and
+       documentation appropriate for either the Python language
+       reference or the standard library reference.
+
+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: