Skip to content

gh-93476: Fraction.limit_denominator speed increase #93477

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mscuthbert wants to merge 7 commits into from
Closed

gh-93476: Fraction.limit_denominator speed increase #93477

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
599c55b
gh-93476: Fraction.limit_denominator speed increases
mscuthbert Jun 3, 2022
70ca7ad
add NEWS.d item
mscuthbert Jun 3, 2022
a1a4fc8
Fix boundary case.
mscuthbert Jun 4, 2022
3c06ded
Review comments
mscuthbert Jun 5, 2022
e5ab32e
trailing space
mscuthbert Jun 5, 2022
40cbe78
return Fraction(self) for limit case
mscuthbert Jun 5, 2022
f5daa21
drop comment for now. can be separate PR
mscuthbert Jun 5, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Review comments 
* Set variable naming according to existing cpython standards
* confirm GCD of returned Fraction, and skip normalization
* Respond and thanks to @mdickinson
  • Loading branch information
@mscuthbert
mscuthbert committed Jun 5, 2022
commit 3c06ded3ee1f152ee7e9467154efc5aa87c34bf2
31 changes: 19 additions & 12 deletions Lib/fractions.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,13 @@ def __new__(cls, numerator=0, denominator=None, *, _normalize=True):
Fraction(147, 100)

"""
# private _normalize=False should only be set if the Fraction is
Comment thread
mscuthbert marked this conversation as resolved.
Outdated
# already asserted to be normalized.
# (see discussion: at https://github.com/python/cpython/pull/93477)
# if a non-normalized Fraction is passed in with _normalize=False
# then API calls may give inconsistent results on equivalent
# Fraction objects.

self = super(Fraction, cls).__new__(cls)

if denominator is None:
Expand Down Expand Up @@ -252,19 +259,19 @@ def limit_denominator(self, max_denominator=1000000):
bound1_d = q0 + k*q1
bound2_n = p1
bound2_d = q1
Comment thread
mscuthbert marked this conversation as resolved.
bound1_minus_self_n = abs((bound1_n * d_original)
- (n_original * bound1_d))
bound1_minus_self_d = d_original * bound1_d
bound2_minus_self_n = abs((bound2_n * d_original)
- (n_original * bound2_d))
bound2_minus_self_d = d_original * bound2_d

difference = ((bound1_minus_self_n * bound2_minus_self_d)
- (bound2_minus_self_n * bound1_minus_self_d))
if difference >= 0:
return Fraction(bound2_n, bound2_d)

# diff1_n = numerator of (bound1 minus self) as a Fraction;
# etc. for diff1_d, diff2_n, diff2_d
diff1_n = abs(bound1_n*d_original - n_original*bound1_d)
diff1_d = d_original * bound1_d
diff2_n = abs(bound2_n*d_original - n_original*bound2_d)
diff2_d = d_original * bound2_d

if diff1_n * diff2_d >= diff2_n * diff1_d:
# bound2 is closer (or equal) to original as bound 1
return Fraction(bound2_n, bound2_d, _normalize=False)
Copy link
Copy Markdown
Member

@mdickinson mdickinson Jun 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realised that I'm not 100% convinced that the result here is always normalised. There are two parts to being normalised: the numerator must be relatively prime to the denominator, and the denominator must be positive. I'd thought about the first part (which is fine), but not about the second.

Is it clear that bound2_d and bound1_d are positive at this point?

Copy link
Copy Markdown
Member

@mdickinson mdickinson Jun 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Answer: yes, it's true that bound2_d and bound1_d are positive at this point, though perhaps not 100% clear. In the Euclidean loop above, on the very first iteration a can be negative, but on all subsequent iterations a is nonnegative. And on the first iteration q1 = 0, so that potentially negative a does no harm, and q0 and q1 are guaranteed nonnegative at all times. Then it's easy to check that they must in fact be positive at the point where the loop exits.

Copy link
Copy Markdown
Author

@mscuthbert mscuthbert Jun 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my reading of the loop as well, but I didn't write the code (nor name the variables) so I didn't want to change this without another set of eyes; thanks!

else:
return Fraction(bound1_n, bound1_d)
return Fraction(bound1_n, bound1_d, _normalize=False)

@property
def numerator(a):
Expand Down