On Wed, Dec 10, 2008 at 6:47 PM, kirby urner <kirby.ur...@gmail.com> 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 Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig