But fractions *can* eat fractions. Instead of Fraction(f1, f2) you just write f1/f2. In general you should just stick to the latter, and leave the Fraction() constructor for when the / operator would pick a different type (as in 1/2, which becomes a float). You can also write it as Fraction(1) / Fraction(2).
--Guido van Rossum (home page: http://www.python.org/~guido/) On Sun, Dec 14, 2008 at 3:05 PM, kirby urner <[email protected]> wrote: > On Wed, Dec 10, 2008 at 6:47 PM, kirby urner <[email protected]> wrote: > > << SNIP >> > >> fractions.Fraction, on the other hand, barfs on anything but integers, >> isn't trying to be all divisions to all possible types, isn't >> pretending this is Mathematica or a generic CAS. >> >> Note that I'm not criticizing fractions.py in any way, am so far quite >> happy with it. I'm simply drawing attention to some fine points. >> > > OK, now I'm going to criticize a little. > > I think the more natural and useful choice would be to continue > threads right here on edu-sig, regarding a Rational Number type, not > just this Fraction type. > > The problem with Fraction is it's not actually much more than the > notion of Ratio (how many times one fits in the other), whereas the > Rational Number concept fits neatly in the sequence: N < W < Z < Q < > R < C, where < could be replaced with the "subset" symbol. Those be > Natural, Whole (Natural + 0), Integers, Rationals, Reals, and Complex > respectively, except the Real type is quite problematic, is treated > with Floats, Decimals and generators (iterable). > > The thing about Rationals is they're a field, closed under + and *, > and therefore - and / (because of field properties). So a Rational is > able to eat other Rationals for breakfast i.e. (1/3) / (3/1) makes > plenty of sense, and all integers are really just rationals in > disguise i.e. 0 = 0/1, 1 = 1/1 etc. > > If Fraction could eat Fraction type objects, then we could have > continued fractions more easily, have other fun. > > The silver lining here is fractions.py was actual named that, and not > rationals.py, which means we still have a hole to fill, a more generic > class, yet not too generic, not open to complex or matrix arguments, > just to rationals, integers a subtype. > > Kirby > _______________________________________________ > Edu-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
