On 2017-09-17 19:59, Chris Angelico wrote:
On Mon, Sep 18, 2017 at 4:35 AM, Steve D'Aprano
<steve+pyt...@pearwood.info> wrote:
So why doesn't it return a fractions.Fraction instead? That way, you
still get "one half" instead of zero, but it's guaranteed to be
accurate. And having 1/3 be a literal meaning "one third" would avoid
all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
justification for int/int => float and not rational?
(1) Guido doesn't like fractions for the built-in maths operators, because of
his experience with ABC where quite simple calculations would end up with
bloody enormous fractions with millions of digits in both the numerator and
denominator, running slower and slower, for a number where the actual precision
was maybe three or four decimal places.
Okay, that's reasonable. A counter-argument is that if you want
reduced accuracy to improve performance, you can always ask for it (by
casting to float), but I do see the disadvantage of slow rationals by
default.
(2) Fractions didn't exist in the standard library when true division was
introduced.
Really? When was true division added? I thought the fractions module
had been there for several 2.x versions.
The fractions module was introduced in Python 2.6.
[snip]
--
https://mail.python.org/mailman/listinfo/python-list
