Spell-checking, grammar, formatting.

pep-0228.txt

@@ -4,43 +4,49 @@ 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 
-    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.
+    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 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.
+    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-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.
+    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 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":
+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()
@@ -50,17 +56,18 @@ Suggested Interface For Python Numerical Model
 
     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).
+    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()
+    - 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.      
+    - 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.
@@ -68,18 +75,21 @@ Suggested Interface For Python Numerical Model
     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.
+    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 using Numerical Python do that for high-performance
-    vector operations. Therefore, NumPy should keep it's hardware
-    based numeric model.
+    People who use Numerical Python do so for high-performance vector
+    operations.  Therefore, NumPy should keep its hardware based
+    numeric model.
+
 
 Unresolved Issues
 
@@ -87,10 +97,12 @@ Unresolved Issues
 
     How do we deal with IEEE 754?
 
+
 Copyright
 
     This document has been placed in the public domain.
 
+
 
 Local Variables:
 mode: indented-text