[Python-checkins] CVS: python/nondist/peps pep-0228.txt,1.2,1.3
Barry Warsaw
python-dev@python.org
Mon, 6 Nov 2000 07:30:02 -0800
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.
+