Mark Dickinson added the comment: Some random comments: take with a large pinch of salt
(1) In __init__ I think you want something like: self._numerator = int(numerator)//g instead of self._numerator = int(numerator / g) and similarly for the denominator. At the moment I get, for example: >>> Rational(10**23) rational.Rational(99999999999999991611392,1) (2) What's the reason for repr of a Rational being "rational.Rational(...)", while repr of a Decimal is just "Decimal(...)"? I'm not suggesting that either is wrong; just wondering whether there's some sort of guiding principle that would suggest one or the other. (3) My first thought on looking at the _gcd function was: "Shouldn't there be an abs() somewhere in there"; since the gcd of two (possibly negative) integers is often (usually?) defined as the largest *nonnegative* common divisor. But on closer examination it's clear that the result of _gcd(a, b) has the same sign as that of b (unless b == 0). So _gcd very cleverly chooses exactly the right sign so that the denominator after rescaling is positive. I'm not sure whether this is a happy accident or clever design, but either way it probably deserves a comment. (4) the __ceil__ operation could be spelt more neatly as return -(-a.numerator // a.denominator) ...but perhaps that just amounts to obfuscation :) (5) It looks as though two-argument round just truncates when the second argument is negative. Presmably this isn't what's wanted here? >>> round(Rational(26), -1) # expecting Rational(30, 1) rational.Rational(20,1) (6) The behaviour of the equality test is questionable when floats are involved. For example: >>> 10**23 == float(10**23) # expect False False >>> Rational(10**23) == float(10**23) # I'd also expect False here True Ideally, if x is a Rational and y is a float then I'd suggest that x == y should return True only when the numeric values really are equal. Coding this could be quite tricky, though. One option would be to convert the float to an (exactly equal) Rational first-- -there's code to do this in the version of Rational.py in the sandbox. (7) For purely selfish reasons, I for one will be very happy if/when this makes it into 2.6/3.0: I use Python a lot for teaching (geometry, number theory, linear algebra, ...); it's natural to work with rational numbers in this context; and it'll be much easier to tell an interested student to just download Python than to tell them they also need gmp and gmpy, or some other third party package, just to try out the code examples I've given them. ---------- nosy: +marketdickinson __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
