Mailing List Archive: Python: Python

Fractions as result from divisions (was: Re: tough-to-explain Python)

Index | Next | Previous | View Threaded

eckhardt at satorlaser

Jul 8, 2009, 2:24 AM

Post #1 of 4 (225 views)
Permalink

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

no.email at please

Jul 8, 2009, 4:59 AM

Post #2 of 4 (210 views)
Permalink

Re: Fractions as result from divisions (was: Re: tough-to-explain Python) [In reply to]

In <c75ei6-e0i.ln1 [at] satorlaser> Ulrich Eckhardt <eckhardt [at] satorlaser> 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

steve at REMOVE-THIS-cybersource

Jul 8, 2009, 5:43 AM

Post #3 of 4 (202 views)
Permalink

Re: Fractions as result from divisions (was: Re: tough-to-explain Python) [In reply to]

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

zephyrfalcon!NO_SPAM! at gmail

Jul 8, 2009, 5:51 AM

Post #4 of 4 (208 views)
Permalink

Re: Fractions as result from divisions [In reply to]

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads