Fractions as result from divisions (was: Re: tough-to-explain Python)
Bearophile wrote: For example a novice wants to see 124 / 38 to return the 62/19 fraction and not 3 or 3.263157894736842 :-) Python has adopted the latter of the three for operator / and the the second one for operator //. I wonder if it was considered to just return a fraction from that operation. x = 3/5 - x = fraction(3, 5) x = x*7 - x = fraction(21, 5) x = x/2 - x = fraction(21, 10) range(x) - error, x not an integer range(int(x)) - [0, 1,] y = float(x) - y = 2.1 This would have allowed keeping the operator what people are used to. On the other hand, implicit conversion to either of float or int would have been avoided, which is usually the #1 cause for subtle problems. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 -- http://mail.python.org/mailman/listinfo/python-list
Re: Fractions as result from divisions (was: Re: tough-to-explain Python)
In c75ei6-e0i@satorlaser.homedns.org Ulrich Eckhardt eckha...@satorlaser.com writes: Bearophile wrote: For example a novice wants to see 124 / 38 to return the 62/19 fraction and not 3 or 3.263157894736842 :-) Python has adopted the latter of the three for operator / and the the second one for operator //. I wonder if it was considered to just return a fraction from that operation. http://www.python.org/dev/peps/pep-0239/ kj -- http://mail.python.org/mailman/listinfo/python-list
Re: Fractions as result from divisions (was: Re: tough-to-explain Python)
On Wed, 08 Jul 2009 11:24:28 +0200, Ulrich Eckhardt wrote: Bearophile wrote: For example a novice wants to see 124 / 38 to return the 62/19 fraction and not 3 or 3.263157894736842 :-) Python has adopted the latter of the three for operator / and the the second one for operator //. Up until a few years ago, / would return the integer division if both arguments where ints or longs, and // didn't even exist. Even in Python 2.6, you still need to do from __future__ import division to get the behaviour you describe. I wonder if it was considered to just return a fraction from that operation. Because of his experience with ABC, Guido dislikes using fractions for standard arithmetic. He was resistant to even allowing the rational module be added to the standard library. The problem with fractions is that, unless you're very careful, repeated arithmetic operations on numbers ends up giving you fractions like 498655847957/569892397664 instead of the 7/8 you were expecting. Not only is that ugly, but it becomes slower and slower as the denominator and numerator become larger. At least, that was Guido's experience. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Fractions as result from divisions
Ulrich Eckhardt wrote: Bearophile wrote: For example a novice wants to see 124 / 38 to return the 62/19 fraction and not 3 or 3.263157894736842 :-) Python has adopted the latter of the three for operator / and the the second one for operator //. I wonder if it was considered to just return a fraction from that operation. http://python-history.blogspot.com/2009/03/problem-with-integer-division.html For example, in ABC, when you divided two integers, the result was an exact rational number representing the result. In Python however, integer division truncated the result to an integer. In my experience, rational numbers didn't pan out as ABC's designers had hoped. A typical experience would be to write a simple program for some business application (say, doing one’s taxes), and find that it was running much slower than expected. After some debugging, the cause would be that internally the program was using rational numbers with thousands of digits of precision to represent values that would be truncated to two or three digits of precision upon printing. This could be easily fixed by starting an addition with an inexact zero, but this was often non-intuitive and hard to debug for beginners. -- Hans Nowak (zephyrfalcon at gmail dot com) http://4.flowsnake.org/ -- http://mail.python.org/mailman/listinfo/python-list
