[Python-checkins] CVS: python/nondist/peps pep-0228.txt,1.2,1.3

[Barry Warsaw]

Update of /cvsroot/python/python/nondist/peps
In directory slayer.i.sourceforge.net:/tmp/cvs-serv23491

Modified Files:
	pep-0228.txt 
Log Message:
Spell-checking, grammar, formatting.


Index: pep-0228.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0228.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -r1.2 -r1.3
*** pep-0228.txt	2000/11/05 20:36:06	1.2
--- pep-0228.txt	2000/11/06 15:29:58	1.3
***************
*** 5,8 ****
--- 5,9 ----
  Status: Draft
  Type: Standards Track
+ Python-Version: ??
  Created: 4-Nov-2000
  Post-History:
***************
*** 10,45 ****
  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()
--- 11,51 ----
  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 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 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-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()
***************
*** 51,65 ****
      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
--- 57,72 ----
      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 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.
  
      There is one important operation, inexact() which takes a number
***************
*** 69,85 ****
      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.
  
  Unresolved Issues
  
--- 76,95 ----
      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 mathematical result.
  
  
  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
  
***************
*** 88,94 ****
--- 98,106 ----
      How do we deal with IEEE 754?
  
+ 
  Copyright
  
      This document has been placed in the public domain.
+