[Python-checkins] CVS: python/nondist/peps pep-0238.txt,1.18,1.19

[Tim Peters]

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

Modified Files:
	pep-0238.txt 
Log Message:
Documented 2.2's approach to long true division (this was implemented
a long time ago).
Spelled out that true division can lose information for ints as well as
longs.
Added a "Resolved Issues" section, and split one of the Open Issues
into three Resolved issues.


Index: pep-0238.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0238.txt,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** pep-0238.txt	2001/10/18 18:00:15	1.18
--- pep-0238.txt	2001/11/05 20:46:08	1.19
***************
*** 319,332 ****
      be the same as classic division.
  
!     Note that for long arguments, true division may lose information;
!     this is in the nature of true division (as long as rationals are
!     not in the language).  Algorithms that consciously use longs
!     should consider using //.
  
      If and when a rational type is added to Python (see PEP 239[2]),
      true division for ints and longs should probably return a
!     rational.  This avoids the problem with true division of longs
!     losing information.  But until then, for consistency, float is the
!     only choice for true division.
  
  
--- 319,341 ----
      be the same as classic division.
  
!     The 2.2 implementation of true division acts as if the float type
!     had unbounded range, so that overflow doesn't occur unless the
!     magnitude of the mathematical *result* is too large to represent
!     as a float.  For example, after "x = 1L << 40000", float(x) raises
!     OverflowError (note that this is also new in 2.2:  previously the
!     outcome was platform-dependent, most commonly a float infinity).  But
!     x/x returns 1.0 without exception, while x/1 raises OverflowError.
! 
!     Note that for int and long arguments, true division may lose
!     information; this is in the nature of true division (as long as
!     rationals are not in the language).  Algorithms that consciously
!     use longs should consider using //, as true division of longs
!     retains no more than 53 bits of precision (on most platforms).
  
      If and when a rational type is added to Python (see PEP 239[2]),
      true division for ints and longs should probably return a
!     rational.  This avoids the problem with true division of ints and
!     longs losing information.  But until then, for consistency, float is
!     the only choice for true division.
  
  
***************
*** 371,383 ****
        library packages available in their environment.
  
-     - For very large long integers, the definition of true division as
-       returning a float causes problems, since the range of Python
-       longs is much larger than that of Python floats.  This problem
-       will disappear if and when rational numbers are supported.  In
-       the interim, maybe the long-to-float conversion could be made to
-       raise OverflowError if the long is out of range.  Tim Peters
-       will make sure that whenever an in-range float is returned,
-       decent precision is guaranteed.
- 
      - For classes to have to support all three of __div__(),
        __floordiv__() and __truediv__() seems painful; and what to do
--- 380,383 ----
***************
*** 385,388 ****
--- 385,419 ----
        maybe at least true division should try __truediv__() first and
        __div__() second.
+ 
+ 
+ Resolved Issues
+ 
+     - Issue:  For very large long integers, the definition of true
+       division as returning a float causes problems, since the range of
+       Python longs is much larger than that of Python floats.  This
+       problem will disappear if and when rational numbers are supported.
+ 
+       Resolution:  For long true division, Python uses an internal
+       float type with native double precision but unbounded range, so
+       that OverflowError doesn't occur unless the quotient is too large
+       to represent as a native double.
+ 
+     - Issue:  In the interim, maybe the long-to-float conversion could be
+       made to raise OverflowError if the long is out of range.
+ 
+       Resolution:  This has been implemented, but, as above, the
+       magnitude of the inputs to long true division doesn't matter; only
+       the magnitude of the quotient matters.
+ 
+     - Issue:  Tim Peters will make sure that whenever an in-range float
+       is returned, decent precision is guaranteed.
+ 
+       Resolution:  Provided the quotient of long true division is
+       representable as a float, it suffers no more than 3 rounding
+       errors:  one each for converting the inputs to an internal float
+       type with native double precision but unbounded range, and
+       one more for the division.  However, note that if the magnitude
+       of the quotient is too *small* to represent as a native double,
+       0.0 is returned without exception ("silent underflow").