Unexpected results comparing float to Fraction

S

Steven D'Aprano

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently they do the opposite: they convert the float
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for
which way numeric coercions should go when doing such comparisons?
 
I

Ian Kelly

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently they do the opposite: they convert the float
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for
which way numeric coercions should go when doing such comparisons?

Any float can be precisely represented as a Fraction. Not so in the
other direction. So from that standpoint it makes sense to me to cast
to Fraction when comparing.
 
M

MRAB

Comparing floats to Fractions gives unexpected results:

# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False

but:

py> 1/3 == float(Fraction(1, 3))
True


I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently they do the opposite: they convert the float
to a Fraction:

py> Fraction(1/3)
Fraction(6004799503160661, 18014398509481984)


Am I the only one who is surprised by this? Is there a general rule for
which way numeric coercions should go when doing such comparisons?
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).
 
C

Chris Angelico

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)?
Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but
not IMO for the Fraction constructor.

ChrisA
 
I

Ian Kelly

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. If it's some other float then
the user didn't get there by entering 1/3, so it's not worth trying to
pretend that they did.

We do a similar rounding when formatting floats to strings, but in
that case one only has to worry about divisors that are powers of 10.
I imagine it's going to take more time to find the correct fraction
when any pair of relatively prime integers can be a candidate
numerator and denominator. Additionally, the string rounding only
occurs when the float is being formatted for display; we certainly
don't do it as the result of numeric operations where it could result
in loss of precision.
 
M

MRAB

At the point where the float is exactly equal to the value you get
from the floating-point division 1/3. If it's some other float then
the user didn't get there by entering 1/3, so it's not worth trying to
pretend that they did.
I thought that you're not meant to check for equality when using floats.
 
T

Terry Reedy

Any float can be precisely represented as a Fraction. Not so in the
other direction.

In other words, there can be multiple unequal Franctions that have the
same float value: for instance, Fraction(1,3) and
Fraction(6004799503160661, 18014398509481984)
So from that standpoint it makes sense to me to cast to
Fraction when comparing.

Otherwise, == becomes non-transitive
 
C

Chris Angelico

At the point where the float is exactly equal to the value you get
from the floating-point division 1/3. If it's some other float then
the user didn't get there by entering 1/3, so it's not worth trying to
pretend that they did.

We do a similar rounding when formatting floats to strings, but in
that case one only has to worry about divisors that are powers of 10.
I imagine it's going to take more time to find the correct fraction
when any pair of relatively prime integers can be a candidate
numerator and denominator.

I imagine it is, and that's where the problem comes in. The true value
is somewhere between (X-0.5)/2**n and (X+0.5)/2**n, or whatever the
actual range is, and finding a "nice" fraction in that range isn't an
instant and direct translation. It's a useful feature, but not IMO
necessary for the constructor.

ChrisA
 
S

Steven D'Aprano

In other words, there can be multiple unequal Franctions that have the
same float value: for instance, Fraction(1,3) and
Fraction(6004799503160661, 18014398509481984)


Otherwise, == becomes non-transitive

This is Python, and we can make __eq__ methods that do anything,
including be non-transitive, non-reflexive, and nonsensical if we like :)

But I take your point, and that makes sense.
 
I

Ian Kelly

I thought that you're not meant to check for equality when using floats.

Equality checking is useful for floats when there is exactly one value
that you want to test for as in this case, as opposed to a range of
approximate values that are considered to be equal within rounding
error. There is exactly one float that the expression 0.1 evaluates
to, and although it's not equal to the decimal 0.1, it is the only
float that we want to format as "0.1". The immediately preceding and
following floats are 0.09999999999999999 and 0.10000000000000002, and
they are formatted as such because they're not equal to the float that
you get from 0.1.
 
R

Rotwang

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.
 
R

Rotwang

At what point should it become Fraction(1, 3)?

Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but
not IMO for the Fraction constructor.

How about this?
Help on function limit_denominator in module fractions:

limit_denominator(self, max_denominator=1000000)
Closest Fraction to self with denominator at most max_denominator.
Fraction(4321, 8765)
Fraction(1, 3)
 
G

Grant Edwards

I thought that you're not meant to check for equality when using floats.

You check for equality if equality is what you want to check. However
much of the time when people _think_ they want to check for FP
equality, they're wrong.

You'll have to consult with a spiritual advisor to determin what you
are "meant" to do...
 
S

Steven D'Aprano

Fraction(5944751508129055, 18014398509481984) [...]Fraction(6004799503160661, 18014398509481984)

Rounding off like that is a job for a cool library function (one of
which was mentioned on this list a little while ago, I believe), but not
IMO for the Fraction constructor.

Or:

py> Fraction(1/3).limit_denominator(100)
Fraction(1, 3)


I think it would be useful for Fraction.from_float() to accept an
optional second argument, the maximum denominator:

Fraction.from_float(x, den=None)
=> nearest fraction to float 1/3, with denominator no greater than den
 
I

Ian Kelly

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?

It should choose the fraction with the least terms that rounds to the
float. Whether "least" here means least numerator, least denominator,
least sum of the two, or whatever is not terribly important.
 
S

Serhiy Storchaka

29.07.13 19:09, MRAB напиÑав(ла):
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).
prev_numer, numer = 0, 1
prev_denom, denom = 1, 0
r = f
while True:
i = math.floor(r)
prev_numer, numer = numer, i * numer + prev_numer
prev_denom, denom = denom, i * denom + prev_denom
if i == r or numer / denom == f:
break
r = 1 / (r - i)

return Fraction(numer, denom)
Fraction(245850922, 78256779)

I guess the Fraction constructor is more faster than this function.
 
S

Steven D'Aprano

I thought that you're not meant to check for equality when using floats.

Heavens no. You're only meant to *mostly* not check for equality using
floats. As Miracle Max might say:

"It just so happens that floats are only MOSTLY inexact. There's a big
difference between mostly inexact and all inexact. Mostly inexact is
slightly exact."


Or to be a little more serious, "never check floats for equality" is
actually pretty lousy advice. As Professor William Kahan puts it, the
word "never" makes it rank superstition.

There are three main problems with the general advice "never check floats
for equality":

1) there are perfectly fine situations where you can check floats
for (in)equality without any problem, e.g.:

if x == 0.0: print "Division by zero"
else: y = 1/x # perfectly safe

2) most of the time, those giving this advice don't actually say
what you should do instead;

3) and when they do, it's often either flat-out wrong, or at least
incomplete.


For example, you might have been told to instead check whether your float
is less than some epsilon:

abs(x - y) < eps

But chances are you've never been given any sort of reliable,
deterministic algorithm for deciding what value eps should have. (Mostly
because there is no such algorithm!) Or for deciding when to use absolute
differences, like the above, and when to use relative differences.

Another issue: if eps is too big, you're taking distinct values and
treating them as the same, which is bad. And if eps is too small, you're
actually doing what you said you should never do, only slower.

E.g. suppose you want to check for a float which equals some value M,
I'll pick M = 2199023255552.0 semi-arbitrarily, but it could be any of
many numbers. You don't want to use equality, so you pick an epsilon:

eps = 1e-6 # seems reasonable...

and then test values like this:

M = 2199023255552.0
if abs(x - M) <= eps:
print("close enough")


That is just a longer and slower way of calculating x == M. Why? Because
the two floats immediately adjacent to M differ by more than your epsilon:

py> M = 2199023255552.0
py> M.hex()
'0x1.0000000000000p+41'
py> float.fromhex('0x1.0000000000001p+41') - M
0.00048828125
py> M - float.fromhex('0x1.fffffffffffffp+40')
0.000244140625

So in this case, any epsilon below 0.000244140625 is just wasting your
time, since it cannot possibly detect any value other than M itself. And
that critical cut-off depends on the numbers you are calculating with.

Oh, for what it's worth, I don't pretend to know how to choose an epsilon
either. I can sometimes recognise a bad epsilon, but not a good one.
Floats are *hard*.
 
I

Ian Kelly

29.07.13 19:09, MRAB напиÑав(ла):

prev_numer, numer = 0, 1
prev_denom, denom = 1, 0
r = f
while True:
i = math.floor(r)
prev_numer, numer = numer, i * numer + prev_numer
prev_denom, denom = denom, i * denom + prev_denom
if i == r or numer / denom == f:
break
r = 1 / (r - i)

return Fraction(numer, denom)

Fraction(245850922, 78256779)

I guess the Fraction constructor is more faster than this function.

You might be able to speed it up a bit with numpy and the observation that
the update is a matrix multiplication. But I don't think that you can get
away from it being an iterative algorithm.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,981
Messages
2,570,188
Members
46,731
Latest member
MarcyGipso

Latest Threads

Top