-
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
Fix QuantumCircuit.depth
with zero-operands and Expr
nodes
#12429
Conversation
This causes `QuantumCircuit.depth` to correctly handle cases where a circuit instruction has zero operands (such as `GlobalPhaseGate`), and to treat classical bits and real-time variables used inside `Expr` conditions as part of the depth calculations. This is in line with `DAGCircuit`. This commit still does not add the same `recurse` argument from `DAGCircuit.depth`, because the arguments for not adding it to `QuantumCircuit.depth` at the time still hold; there is no clear meaning to it for general control flow from a user's perspective, and it was only added to the `DAGCircuit` methods because there it is more of a proxy for optimising over all possible inner blocks.
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 9128390726Details
💛 - Coveralls |
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! I only have one minor comment.
@@ -3307,6 +3307,9 @@ def depth( | |||
) -> int: | |||
"""Return circuit depth (i.e., length of critical path). | |||
|
|||
.. warning:: | |||
This operation is not well defined if the circuit contains control-flow operations. |
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.
would it make sense to add more info in this warning? would it be inaccurate to say, for example:
This operation is not well defined if the circuit contains control-flow operations. | |
This operation is not well defined if the circuit contains control-flow operations, but | |
their variables and clbits are counted in the depth calculation. | |
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 was mostly deliberately trying to avoid saying anything about what happens in the return value of this if there's control-flow operations, since the whole result is ill defined. I didn't want to commit to anything one way or the other.
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 suspected that was the case, and I think that makes sense too.
@@ -3307,6 +3307,9 @@ def depth( | |||
) -> int: | |||
"""Return circuit depth (i.e., length of critical path). | |||
|
|||
.. warning:: | |||
This operation is not well defined if the circuit contains control-flow operations. |
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 suspected that was the case, and I think that makes sense too.
This causes `QuantumCircuit.depth` to correctly handle cases where a circuit instruction has zero operands (such as `GlobalPhaseGate`), and to treat classical bits and real-time variables used inside `Expr` conditions as part of the depth calculations. This is in line with `DAGCircuit`. This commit still does not add the same `recurse` argument from `DAGCircuit.depth`, because the arguments for not adding it to `QuantumCircuit.depth` at the time still hold; there is no clear meaning to it for general control flow from a user's perspective, and it was only added to the `DAGCircuit` methods because there it is more of a proxy for optimising over all possible inner blocks. (cherry picked from commit d18a74c)
… (#12528) This causes `QuantumCircuit.depth` to correctly handle cases where a circuit instruction has zero operands (such as `GlobalPhaseGate`), and to treat classical bits and real-time variables used inside `Expr` conditions as part of the depth calculations. This is in line with `DAGCircuit`. This commit still does not add the same `recurse` argument from `DAGCircuit.depth`, because the arguments for not adding it to `QuantumCircuit.depth` at the time still hold; there is no clear meaning to it for general control flow from a user's perspective, and it was only added to the `DAGCircuit` methods because there it is more of a proxy for optimising over all possible inner blocks. (cherry picked from commit d18a74c) Co-authored-by: Jake Lishman <[email protected]>
…t#12429) This causes `QuantumCircuit.depth` to correctly handle cases where a circuit instruction has zero operands (such as `GlobalPhaseGate`), and to treat classical bits and real-time variables used inside `Expr` conditions as part of the depth calculations. This is in line with `DAGCircuit`. This commit still does not add the same `recurse` argument from `DAGCircuit.depth`, because the arguments for not adding it to `QuantumCircuit.depth` at the time still hold; there is no clear meaning to it for general control flow from a user's perspective, and it was only added to the `DAGCircuit` methods because there it is more of a proxy for optimising over all possible inner blocks.
Summary
This causes
QuantumCircuit.depth
to correctly handle cases where a circuit instruction has zero operands (such asGlobalPhaseGate
), and to treat classical bits and real-time variables used insideExpr
conditions as part of the depth calculations. This is in line withDAGCircuit
.This commit still does not add the same
recurse
argument fromDAGCircuit.depth
, because the arguments for not adding it toQuantumCircuit.depth
at the time still hold; there is no clear meaning to it for general control flow from a user's perspective, and it was only added to theDAGCircuit
methods because there it is more of a proxy for optimising over all possible inner blocks.Details and comments
Fix #12426.