From 8ef21606a8ba00f9156e9460719ebe53fe86a432 Mon Sep 17 00:00:00 2001 From: Tim Peters Date: Mon, 5 Nov 2001 20:46:08 +0000 Subject: [PATCH] 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. --- pep-0238.txt | 63 +++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 47 insertions(+), 16 deletions(-) diff --git a/pep-0238.txt b/pep-0238.txt index b6c5b3060..bcd0da210 100644 --- a/pep-0238.txt +++ b/pep-0238.txt @@ -318,16 +318,25 @@ Semantics of True Division return a float (2.0), not an int. For floats and complex, it will 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 //. + 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 longs - losing information. But until then, for consistency, float is the - only choice for true division. + 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. The Future Division Statement @@ -370,15 +379,6 @@ Open Issues need the same. These usually have enough control over the 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 in 3.0? Maybe we only need __div__() and __floordiv__(), or @@ -386,6 +386,37 @@ Open Issues __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"). + + FAQ Q. When will Python 3.0 be released?