Optimistic backjumping with cutoff #188
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
notatallshaw
force-pushed
the
optimistic-backjumping-with-cutoff
branch
from
301c1a7 to
814715c
Compare
notatallshaw
force-pushed
the
optimistic-backjumping-with-cutoff
branch
from
814715c to
207da9a
Compare
Closed
Collaborator
Author
|
@uranusjr @frostming Any thoughts on this? In an ideal world I would like to see this released so I can get this in the next version of Python. It solves 7 out of the 8 ResolutionTooDeep errors I have open against pip without introducing any new ones. |
Member
|
LGTM from my side. |
Collaborator
Author
|
Okay, I'll leave it a few more days if anyone else wants to comment and then merge. And then look to do a release shortly there after (not sure if I have required permissions, will open an issue for a release and we'll see how it goes). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #180
This implements #180 (comment) with a ratio of 10%.
10% is somewhat arbitrary, but the general idea is optimistic backtracking is supposed to be much faster than regular backtracking, and therefore if it is taking a significant amount of the remaining rounds left it is probably going down the wrong path. I tried several different numbers for different max rounds on real world and synthetic cases and found between 5% and 20% tended to work best.
While not intended to be changed I have made
_OPTIMISTIC_BACKJUMPING_RATIOa global as an easy way for a knowledgeable motivated resolvelib user to pick a different ratio (in particular they may want to pick 0 or 1).I have added additional tests that fail without optimistic backjumping (i.e. optimistic backjumping is able to skip over certain requirements that regular backjumping can not). I also test turning off optimistic backjumping to make sure all other tests pass without it.
(Note: I have collected recent problematic real world examples in pypa/pip#13281 and have been documenting them in problematic.toml).