-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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.
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
Expose Sabre heuristic configuration to Python (backport #12171) #12856
Conversation
* Expose Sabre heuristic configuration to Python This exposes the entirety of the configuration of the Sabre heuristic to Python space, making it modifiable without recompilation. This includes some additional configuration options that were not previously easily modifiable, even with recompilation: - the base weight of the "basic" component can be adjusted - the weight of the "basic" and "lookahead" components can be adjusted to _either_ use a constant weight (previously not a thing) or use a weight that scales with the size of the set (previously the only option). - the "decay" component is now entirely separated from the "lookahead" component, so in theory you can now have a decay without a lookahead. This introduces a tracking `Vec` that stores the scores of _all_ the swaps encountered, rather than just dynamically keeping hold of the best swaps. This has a couple of benefits: - with the new dynamic structure for heuristics, this is rather more efficient because each heuristic component can be calculated in separate loops over the swaps, and we don't have to branch within the innermost loop. - it makes it possible in the future to try things like assigning probabilities to each swap and randomly choosing from _all_ of them, not just the best swaps. This is something I've actively wanted to try for quite some time. The default heuristics in the transpiler-pass creators for the `basic`, `lookahead` and `decay` strings are set to represent the same heuristics as before, and this commit is entirely RNG compatible with its predecessor (_technically_ for huge problems there's a possiblity that pulling out some divisions into multiplications by reciprocals will affect the floating-point maths enough to modify the swap selection). * Update for PyO3 0.21 * Increase documentation of heuristic components (cherry picked from commit 43d8372)
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 10165244742Details
💛 - Coveralls |
Summary
This exposes the entirety of the configuration of the Sabre heuristic to Python space, making it modifiable without recompilation. This includes some additional configuration options that were not previously easily modifiable, even with recompilation:
This introduces a tracking
Vec
that stores the scores of all the swaps encountered, rather than just dynamically keeping hold of the best swaps. This has a couple of benefits:The default heuristics in the transpiler-pass creators for the
basic
,lookahead
anddecay
strings are set to represent the same heuristics as before, and this commit is entirely RNG compatible with its predecessor (technically for huge problems there's a possiblity that pulling out some divisions into multiplications by reciprocals will affect the floating-point maths enough to modify the swap selection).Details and comments
I need to run more formal benchmarks on this to verify the claims in the commit message - it's possible I didn't do it sufficiently well earlier, and at any rate I no longer have the data to hand. (edit: come to think of it, I'm not even sure I ran the tests...)
I so far have not documented the newly available API stuff from Rust-space here, because I didn't necessarily want to commit to it as public interface, but did want to make it available for research - certainly I found this very useful in investigating Sabre, even if I haven't had time to turn that research into a full set of tweaked heuristics yet or anything. Happy to discuss whether we should commit to this as public API - there's probably not too much risk.
This is an automatic backport of pull request #12171 done by Mergify.