remove_final_measurements leaves clbit unusable
See original GitHub issuec = QuantumCircuit(2, 5)
c.measure(0, 0)
c.measure(1, 1)
print(c)
┌─┐
q_0: ┤M├───
└╥┘┌─┐
q_1: ─╫─┤M├
║ └╥┘
c: 5/═╩══╩═
0 1
c.remove_final_measurements(inplace=True)
print(c)
q_0:
q_1:
c: 5/
c.measure(0, 0) # raises error
Note that as currently defined, remove_final_measurements() is supposed to remove the measurements plus the classical bits. But evidently it does not do that (looking at the two circuits above). Still, the clbit is unusable.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Release Notes — Qiskit 0.37.0 documentation
Qiskit Metapackage Version qiskit‑terra qiskit‑aer qiskit‑ignis qiskit‑ibmq‑provider Release...
0.37.0 0.21.0 0.10.4 0.19.2 2022‑06...
0.36.2 0.20.2 0.10.4 0.7.1 0.19.1 2022‑05...
0.36.1 0.20.1 0.10.4 0.7.0 0.19.1 2022‑04...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I rewrote the final op determination logic to match the original doc string, while preserving @mtreinish’s bottom-up approach, and resolving a bug that existed in the implementation even before #7039.
Working on fixing other discussed issues with creg removal currently.
While working on this, I noticed that the current behavior of the
RemoveFinalMeasurements
pass doesn’t match its doc string. Specifically,Currently, a measurement or barrier is only removed if it immediately precedes a qubit’s output node in the DAG. Only the final measurement or barrier will be removed in a chain of successive measure and barrier calls.
What’s the correct behavior here? Perhaps we should add a parameter to support either scenario. In that case, I wonder which should be the default?
I’m happy to address this while fixing the other issues discussed so far here.
@mtreinish @georgios-ts @kdk @ajavadia