On 29/07/2013 17:40, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico <ros...@gmail.com> wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB <pyt...@mrabarnett.plus.com> wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
At what point should it become Fraction(1, 3)?
At the point where the float is exactly equal to the value you get
from the floating-point division 1/3.
But the interpreter has no way of knowing that the value 1/3 that's been
passed to the Fraction constructor was obtained from the division 1/3,
rather than, say, 100000000000000001/300000000000000000 or
6004799503160661/18014398509481984. How do you propose the constructor
should decide between the many possible fractions that round to the same
float, if not by choosing the one that evaluates to it exactly?
Personally the behaviour in the OP is exactly what I would expect.
--
http://mail.python.org/mailman/listinfo/python-list
