[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 2017-09-17 19:59, Chris Angelico wrote: > On Mon, Sep 18, 2017 at 4:35 AM, Steve D'Aprano > <steve+python at 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]

- Prev by Date:
**Old Man Yells At Cloud** - Next by Date:
**Unicode** - Previous by thread:
**Old Man Yells At Cloud** - Next by thread:
**Old Man Yells At Cloud** - Index(es):