-
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
Add default
translation stage plugin
#13794
Conversation
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 13168256573Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
This is added to give us semantic room to play with the default translation algorithm during the 2.x series. It starts life as an alias to `translator`, but may change to improve support for fractional-gate translation, more optimized synthesis routines, or discrete-basis translations (like a SK-based 1q translator for logical backends). This makes it programmatically possible to distinguish the "default" plugin choice from an explicit "translator" choice, even when (as right now) those are the same thing. Note that `pass_manager_config` uses `None` as an implicit default, but we active suggest using the plugin-stage getters, which need an actual plugin name.
5190941
to
fa26efb
Compare
Now rebased over |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually triggered by things like this but even after reviewing the new docs I didn't realize that the translation stage was missing a default plugin. I think the change looks good and makes sense (but I will leave the PR around for a bit in case anyone has further opinions)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I'm looking forward to finally transpiling to a discrete basis out of the box 😄
Ha, I think we've got quite some way to go still til then, but this at least gives us semantic leeway to make changes to the algorithm we use by default to move that way. |
This is added for a similar reason as the recent `default` translation-stage plugin (Qiskitgh-13794). We currently have no plans to change the default routing method, if not only because the `default` layout plugin does routing most of the time, but this makes the semantics of "just use the default method" clearer.
This is added for a similar reason as the recent `default` translation-stage plugin (Qiskitgh-13794). We currently have no plans to change the default routing method, if not only because the `default` layout plugin does routing most of the time, but this makes the semantics of "just use the default method" clearer.
Summary
This is added to give us semantic room to play with the default translation algorithm during the 2.x series. It starts life as an alias to
translator
, but may change to improve support for fractional-gate translation, more optimized synthesis routines, or discrete-basis translations (like a SK-based 1q translator for logical backends).This makes it programmatically possible to distinguish the "default" plugin choice from an explicit "translator" choice, even when (as right now) those are the same thing. Note that
pass_manager_config
usesNone
as an implicit default, but we active suggest using the plugin-stage getters, which need an actual plugin name.Details and comments
Close #13788.
Built on top of the enhanced documentation #13620.