-
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 Expr
support to DAGCircuit.compose
#10377
Conversation
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5602299220
💛 - Coveralls |
e0493bc
to
ac942ee
Compare
The remapping facilities are (except for some esoteric behaviour for mapping registers to others in a different order) the same as for `QuantumCircuit`, so it makes sense to unify the handling. As part of switching the old `DAGCircuit` classical-resource-mapping methods over to the new general-purpose forms, this does most of the necessary work to upgrade `substitute_node_with_dag` as well.
ac942ee
to
aa50bec
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.
LGTM, one minor comment.
If an ``add_register`` callable is given to the initialiser, the mapper will use it to attempt | ||
to add new aliasing registers to the outer circuit object, if there is not already a suitable | ||
register for the mapping available in the circuit. If this parameter is not given, the mapping | ||
function will raise an exception of type ``exc_type`` instead. |
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.
Can we instead just leave it up to the caller to throw their own exception from the add_register
callable they pass in?
It looks like we only use this once in DAGCircuit
, and IMO the extra parameter (and thusly required defaulting) and docstring aren't worth it given that this is a private interface.
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.
Yeah, that sounds reasonable. Doing that marginally compromises the available error message (since you don't get the original register), but it's probably not so important. I've done a version of this in 591cbaa.
Instead, we just delegate this down to a passed-in `add_register`, if desired. It marginally compromises the error messages that might be emitted, but those are paths that we're hope to reduce use of anyway.
* Add `Expr` support to `DAGCircuit.compose` The remapping facilities are (except for some esoteric behaviour for mapping registers to others in a different order) the same as for `QuantumCircuit`, so it makes sense to unify the handling. As part of switching the old `DAGCircuit` classical-resource-mapping methods over to the new general-purpose forms, this does most of the necessary work to upgrade `substitute_node_with_dag` as well. * Remove `exc_type` argument from `VariableMapper` Instead, we just delegate this down to a passed-in `add_register`, if desired. It marginally compromises the error messages that might be emitted, but those are paths that we're hope to reduce use of anyway.
Summary
The remapping facilities are (except for some esoteric behaviour for mapping registers to others in a different order) the same as for
QuantumCircuit
, so it makes sense to unify the handling. As part of switching the oldDAGCircuit
classical-resource-mapping methods over to the new general-purpose forms, this does most of the necessary work to upgradesubstitute_node_with_dag
as well.Details and comments
Resolve #10230. Depends on #10375 (since I elected to generalise some of the new handling from that PR). Changelog in #10331.