Some enhancements, based on Tim's urges to clarify.

pep-0228.txt

@@ -14,19 +14,19 @@ Abstract
     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
+    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 very surprising to Python programmers.
+    2/3 == 0, it is surprising to Python programmers.
 
 
 Rationale
 
-    In usability studies, one of Python features hardest to learn was
+    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 easier numerical model would stem
-    from the mathematical understanding of numbers.
+    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
@@ -56,8 +56,9 @@ Suggested Interface For Python's 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.
+    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
@@ -69,19 +70,36 @@ Suggested Interface For Python's Numerical Model
     - 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
+    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 operations will return exact numbers
-    when given inexact numbers: e.g, int().
+    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 will
-    return the correct mathematical result.
+    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
@@ -95,7 +113,8 @@ Unresolved Issues
 
     Which number literals will be exact, and which inexact?
 
-    How do we deal with IEEE 754?
+    How do we deal with IEEE 754 operations? (probably, isnan/isinf should
+    be methods)
 
 
 Copyright