-
Notifications
You must be signed in to change notification settings - Fork 48
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
BarrierOp
and Circuit._add_conditional_barrier
#988
Conversation
Remove `OpType::Barrier` from `MetaOp`
unsigned and UnitID constructors
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.
Thanks, code looks good. One suggestion I'd make, before merging this, would be to build a wheel and verify that it solves the problem this was designed to solve. Because it does feel like a strange feature -- "conditional barrier" doesn't really have semantic meaning at the circuit level (condition is evaluated at runtime; barrier is a compile-time annotation.)
Good idea. I've messaged Dominic to check that the |
Dominic has confirmed that the output qasm is as expected. |
Adds a new method to the
Circuit
object_add_conditional_barrier
.Previously
OpType::Barrier
was classified as aMetaOp
. However, it seemed a bit at odds with otherMetaOp
, taking a variable number and mix ofUnitID
, and having special case handling for being added to aCircuit
by a user, while otherMetaOp
can't be.Given this, this new additional caveat of being to add them as a conditional gate seemed like a step far enough to make them a new child
Op
BarrierOp
. Happy to undo this work and just have as a special caseMetaOp
if preferred though.I have made the method "hidden" currently as it is unusual functionality - but obviously we can give it a normal name if we prefer.