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

Moshe Zadka moshez@users.sourceforge.net
Tue, 27 Feb 2001 13:01:24 -0800


Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv11533

Modified Files:
	pep-0228.txt 
Log Message:
Some enhancements, based on Tim's urges to clarify.


Index: pep-0228.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0228.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -r1.3 -r1.4
*** pep-0228.txt	2000/11/06 15:29:58	1.3
--- pep-0228.txt	2001/02/27 21:01:22	1.4
***************
*** 15,31 ****
      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.
  
  
--- 15,31 ----
      between numerical types are requested, coercions happen.  While
      the C rationale for the numerical model is that it is very similar
!     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 surprising to Python programmers.
  
  
  Rationale
  
!     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 model that might be easier to work with 
!     can be based on the mathematical understanding of numbers.
  
  
***************
*** 57,62 ****
      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.)
  
--- 57,63 ----
      a. isexact()
  
!     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.)
  
***************
*** 70,79 ****
        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
--- 71,95 ----
        they might be only approximately true.
  
!     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 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
***************
*** 81,86 ****
      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.
  
  
--- 97,104 ----
      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 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.
  
  
***************
*** 96,100 ****
      Which number literals will be exact, and which inexact?
  
!     How do we deal with IEEE 754?
  
  
--- 114,119 ----
      Which number literals will be exact, and which inexact?
  
!     How do we deal with IEEE 754 operations? (probably, isnan/isinf should
!     be methods)