-
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
Circuits containing Clifford
ops raise a lot of exceptions
#9159
Comments
Hi @chriseclectic, it looks like my PR #7966 on natively adding Cliffords to quantum circuits broke the above functionality, sorry! Most of these should be easy to fix, for instance the very first problem is caused by that after the above changes we don't know how to build a
just before checking |
Having |
This isn't correct - For the same reason, we absolutely should not be adding Obviously there are real issues here - there's clearly behaviour that was missed when the update to In the general case, we need to know what the replacement strategy is for code that currently relies on |
@chriseclectic, are any of these problems more urgent than others? E.g., would it make sense to commit the fix for creating Cliffords from QuantumCircuits that contain Cliffords, while we are evaluating options on how to properly handle BTW, one can always explicitly convert
I should have explained the motivation for these recent changes. There are real benefits of not converting a |
@alexanderivrii I would say are things like @jakelishman I'm not suggesting you should go back to the old implementation, but the end user behaviour should have been equivalent before introducing these as this has introduced changes without any warning which can break existing code. There are lot of methods in QuantumCircuit and quantum_info classes (and likely other places) which assume that all circuit members are instructions, so these all need to be updated to handle these new non-instruction circuit member types, along with a lot more unit tests to cover these sorts of errors. |
Chris: maybe it wasn't clear, but what you said is exactly what I meant. |
The PR #9169 fixes I am still unsure what is the best way to fix |
As written above, |
Thanks Shelly, I completely agree that explicitly adding methods like |
Environment
What is happening?
Circuits containing
Clifford
operations cannot currently be used with the same classes used to construct them.How can we reproduce the issue?
Some examples:
Initializing a
Clifford
orStabilzierState
from circuit fails with following exception:Similarly for other methods that should work with Clifford circuits,
Clifford.compose
,Pauli.evolve
, etc.These circuits cause a bunch of circuit methods to break. For example
circuit.inverse()
Reverse ops:
Conditionals:
The above examples are likely not an exhaustive list since it looks like the Clifford's added to the circuit are not valid
Instructions
, and hence circuit methods and functions that consume circuits assuming this are breaking.What should happen?
I would expect Cliffords to behave like any other unitary gate instructions and all of the above methods to work as they used to when Cliffords were greedily synthesized to gate when being added to circuits.
Any suggestions?
Clifford's added to circuits should satisfy semantics of unitary Gate
Instructions
so that circuit methods can work correctly with themThe text was updated successfully, but these errors were encountered: