Pauli X, Y, Z measurement instructions #9269

pedrorrivero · 2022-12-08T23:00:33Z

Summary

This PR introduces MeasureX, MeasureY, and MeasureZ instructions with the corresponding measure_x, measure_y, and measure_z methods in QuantumCircuit.

Details and comments

The Measure instruction is used as the parent class for all three new instructions, and an optional basis class attribute is added. Otherwise it is left untouched for backwards compatibility.

Ideally, I would suggest progressively moving away from Measure and towards MeasureZ (we can always keep the QuantumCircuit.measure method as an alias), keeping the former exclusively as a common parent (abstract) class. Suggestions on how to proceed with this —if possible— would be greatly appreciated.

Picks up where Pauli-X measurement instruction #7716 left.
Closes Add x and y measurements #3967

qiskit-bot · 2022-12-08T23:00:41Z

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

@Cryoris
@Qiskit/terra-core
@ajavadia
@enavarro51

qiskit/circuit/measure.py

pedrorrivero · 2022-12-09T18:18:05Z

qiskit/dagcircuit/dagdependency.py

-        directives = ["measure"]
-        if not getattr(operation, "_directive", False) and operation.name not in directives:
+        directives = []
+        if (
+            not getattr(operation, "_directive", False)
+            and not isinstance(operation, Measure)
+            and operation.name not in directives
+        ):


After introducing the isinstance check to harness subclassing, directives became empty. Should it be removed? If kept, I would suggest turning it into a set instead of a list.

coveralls · 2022-12-09T18:24:24Z

Pull Request Test Coverage Report for Build 3669879986

44 of 70 (62.86%) changed or added relevant lines in 10 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 84.533%

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/visualization/circuit/latex.py	3	5	60.0%
qiskit/visualization/circuit/matplotlib.py	1	3	33.33%
qiskit/circuit/quantumcircuit.py	4	7	57.14%
qiskit/visualization/circuit/text.py	7	10	70.0%
qiskit/circuit/measure.py	17	33	51.52%

Totals
Change from base Build 3658575673:	-0.02%
Covered Lines:	63594
Relevant Lines:	75230

💛 - Coveralls

yaelbh · 2022-12-11T10:04:47Z

@pedrorrivero Thanks for resuming #7716. I recommend to carefully read the discussion there and in #5311. In particular, there has been a question about the RemoveFinalMeasurements pass manager. What's its expected behavior for MeasureX and MeasureY, and is it the actual behavior implemented in the code?

nonhermitian · 2022-12-11T15:21:31Z

I am also curious how this works with the ResetAfterMeasureSimplification pass that is extremely important to use on IBM Quantum systems for dynamic circuits? Does one have to run this before decomposing to basis gates to get the expected result?

Also, is there a pass that removes the extra gates after the measurement if they come at the end of a circuit?

pedrorrivero · 2022-12-11T16:04:12Z

Hi @yaelbh and @nonhermitian ! Thanks so much for your comments.

I have not implemented that yet, left it for last to have more time to think, but this is what I am planning:

RemoveFinalMeasurements will operate by checking isinstance(..., Measure), leveraging the parent-child relationship that I set up, and therefore removing these new instructions as well (as @1ucian0 requested).
If the gate is decomposed before applying RemoveFinalMeasurements, the latter becomes a no-op due to the extra gates added after measuring to return to the computational basis (i.e. except for MeasureZ). This may not be ideal, but feels like a tradeoff for users to make. I will take a look at ResetAfterMeasureSimplification @nonhermitian , there currently is not a pass that removes the extra gates after the measurement if they come at the end of a circuit, would it be required for this PR?
@ikkoham suggested an option where one could keep the basis rotation and remove the final measurements. This is not implemented here, but it would be good for another PR. My suggestion would be to extend the the functionality of remove_final_measurements so that that it accepts an optional keep_basis_rotation kwarg. Depending on how we address [2], this could be achieved by decomposing, removing the extra gates, and removing final measurements.
As for the discussion on calibration, I like this idea a lot. As a matter of fact, my original inspiration for this PR came from considering adding these gates to the basis set and letting the hardware handle base rotations in the most efficient way possible —abstracting it out for the users. This could be particularly beneficial for the combination Sdg•H in MeasureY. Alternatively, it could be handled at compile time. If certain backend does not support them in the basis set, it could always be handled via decomposition. This falls outside the scope of this PR however, @nkanazawa1989 @ajavadia.
This implementation seems more versatile than to "build a mechanism in Aer that detects Pauli measurement instructions", which was the suggested alternative.

Thoughts anyone? Thanks!

jakelishman

I am keen to see X and Y measurements implemented somehow in Qiskit - it certainly seems like a generally useful feature. Thanks for picking up the thread of work again.

I'm concerned with introducing inheritance to the data model, though - in this situation it could be acceptable, but I'm not certain. It could be that OO hierarchy isn't the best fit possible - it definitely isn't for other quantum operations. Aside from those given in the PR, I can think of a couple of other potential advantages of subclassing though, but it's a bit long for me to type out on my phone.

I'd like to be involved in more discussion on this once I'm back from holiday in January - I can't really give a full review or think things through completely right now.

On Paul's point: in general, we should assume that most non-Z measurements will be decomposed/basis-translated before ResetSimplification and RemoveFinalMeasurements run; it's certainly the case right now, and while that could change, I can imagine other cases where Measure might appear in compound instructions that we'd want to handle well. I think it would be completely acceptable (and clearer) to handle that in a follow-up PR, though.

jakelishman · 2022-12-11T16:19:30Z

qiskit/visualization/circuit/latex.py

+                    \\endxy
+                } 
+                \\POS ="i",
+                "i"+UR;"i"+UL **\\dir{-};"i"+DL **\\dir{-};"i"+DR **\\dir{-};"i"+UR **\\dir{-},


(On my phone so I can't select properly.)

This looks like qcircuit code. That's GPL licensed, so we legally cannot include it, or code derived from it, in Qiskit. We need to be really careful when copying code blocks like this - attribution is not generally sufficient. It's legally tricky for us now even if you try and write your own implementation, because it's hard to be certain that it wouldn't be a derived work.

Perhaps we can use their \measure macro somehow?

Ah! Good catch, I have definitely derived it from their code.

I did try to use their macro but it proved to be very challenging (it builds an image and you lose the reference points after wrapping it up) so I dropped down to base xypic code and recreated part of what they where doing adding the extra pieces. I have reached out to them to see if I can contribute this to their package.

Not sure how to address this otherwise. I'll think about it, thanks for bringing this up.

I opened a PR to contribute this piece of code to qcircuit

jakelishman · 2022-12-11T16:29:33Z

qiskit/circuit/measure.py

 import warnings

 from qiskit.circuit.instruction import Instruction
 from qiskit.circuit.exceptions import CircuitError


+# Measure class kept for backwards compatibility, and repurposed
+# as a common parent class for all measurement instructions.
 class Measure(Instruction):


It's possible that we could accept an inheritance relationship here, but I don't think it's for certain the correct way of doing things, over (for example) a set of flags defined Instruction or Operation. This particular inheritance is definitely not safe, though - Measure is, and needs to remain, a measure in the Z basis, so MeasureX isn't an instance of it. There's also the false abstraction here that the base class is only abstract as far as a single-qubit Pauli-basis measurement, which isn't the most general type.

Aside from those abstraction/false-hierarchy issues, another thing to consider with inheritance is that we would need to work out how external / further subclasses of BaseMeasure (or whatever) would be safely serialised/deserialised by QPY - this PR adds an inheritance structure to instructions that is deliberately avoided in our data model elsewhere. This has some wide-ranging implications that I'm too "on holiday" to think through properly right now (sorry).

I see 🤔 let's pick this up again once you come back then! Thanks for the detailed explanation

nonhermitian · 2022-12-11T17:07:31Z

I would also add that this code might be hardware specific. Ie there might be hardware that can natively measure in more than one basis. At present, this is a hypothetical and/or I didn't bother to do my homework, but if that situation ever arises, then this code doesn't cover that.

pedrorrivero · 2022-12-11T17:22:37Z

Thanks @nonhermitian, I am not sure I follow though 🤔

If some hardware shows up in the future that can handle (say) MeasureX directly, what would be preventing it from not decomposing the gate and simply performing it? Isn't this effectively another flavor of what I was discussing in [4] related to calibration?

pedrorrivero · 2022-12-11T17:23:53Z

Per @jakelishman's comments, it may be better to follow this data model instead.

Open to comments/suggestions!

nonhermitian · 2022-12-11T17:26:16Z

Perhaps it does. However, I am not sure what happens to a decomposition over eg measure_x, measure_z, and measure. Also where does the measurement info go? Hopefully not basis gates as we have abused that notion enough. Perhaps it is handled in backend v2, but I have not played with that.

jrj-d · 2023-03-04T21:19:12Z

Hi everyone! Thanks for the work on this PR and the insightful discussions. I work at Alice & Bob, a company developing cat qubits. MeasureX is an instruction that we support natively, so I'm eager to see it included in Qiskit.
I worte a message mainly to say that harware supporting measurement in other bases does exist :)
I'm not familiar with the internals of Qiskit yet, but I'll dig into it and contribute to the discussions.

(On top of this PR, we'll also need support for measurements in other bases in qiskit-aer, so that we can attach a specific noise to MeasureX for simulation purposes. I'll try to contribute there as well. But I understand this is unrelated to this PR.)

pedrorrivero requested review from a team and nonhermitian as code owners December 8, 2022 23:00

pedrorrivero added 9 commits December 9, 2022 12:58

Add MeasureX, MeasureY, and MeasureZ instructions

43b702b

Fix lint

0f796bd

Update dagdependency

7c04baa

Add text visualization

2bc2c92

Add matplotlib visualization

882dad9

Fix cregbundle visualization

49c608e

Remove unused imports

125e5fc

Fix lint

de2df75

Fix MeasureZ.__init__ docstring position

b3fd53e

pedrorrivero force-pushed the pauli-measurement branch from 230a3ca to b3fd53e Compare December 9, 2022 17:59

Add missing display colors

d34b69b

pedrorrivero commented Dec 9, 2022

View reviewed changes

qiskit/circuit/measure.py Outdated Show resolved Hide resolved

pedrorrivero commented Dec 9, 2022

View reviewed changes

pedrorrivero added 3 commits December 9, 2022 17:39

Add latex visualization

0e50b05

Remove deprecation TODO

8ec2965

Rename LATEX_METER to PAULI_METER

6421275

Update RemoveFinalMeasurements

7144f26

jakelishman requested changes Dec 11, 2022

View reviewed changes

jakelishman mentioned this pull request Mar 8, 2023

[WIP] introduce GroupingMeasure class #9750

Closed

jakelishman mentioned this pull request Dec 20, 2023

Add x and y measurements #3967

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pauli X, Y, Z measurement instructions #9269

Pauli X, Y, Z measurement instructions #9269

pedrorrivero commented Dec 8, 2022 •

edited

Loading

qiskit-bot commented Dec 8, 2022

pedrorrivero Dec 9, 2022

coveralls commented Dec 9, 2022 •

edited

Loading

yaelbh commented Dec 11, 2022

nonhermitian commented Dec 11, 2022 •

edited

Loading

pedrorrivero commented Dec 11, 2022 •

edited

Loading

jakelishman left a comment

jakelishman Dec 11, 2022

pedrorrivero Dec 11, 2022 •

edited

Loading

pedrorrivero Dec 12, 2022

jakelishman Dec 11, 2022

pedrorrivero Dec 11, 2022

nonhermitian commented Dec 11, 2022

pedrorrivero commented Dec 11, 2022

pedrorrivero commented Dec 11, 2022 •

edited

Loading

nonhermitian commented Dec 11, 2022

jrj-d commented Mar 4, 2023

Pauli X, Y, Z measurement instructions #9269

Are you sure you want to change the base?

Pauli X, Y, Z measurement instructions #9269

Conversation

pedrorrivero commented Dec 8, 2022 • edited Loading

Summary

Details and comments

qiskit-bot commented Dec 8, 2022

pedrorrivero Dec 9, 2022

Choose a reason for hiding this comment

coveralls commented Dec 9, 2022 • edited Loading

Pull Request Test Coverage Report for Build 3669879986

💛 - Coveralls

yaelbh commented Dec 11, 2022

nonhermitian commented Dec 11, 2022 • edited Loading

pedrorrivero commented Dec 11, 2022 • edited Loading

jakelishman left a comment

Choose a reason for hiding this comment

jakelishman Dec 11, 2022

Choose a reason for hiding this comment

pedrorrivero Dec 11, 2022 • edited Loading

Choose a reason for hiding this comment

pedrorrivero Dec 12, 2022

Choose a reason for hiding this comment

jakelishman Dec 11, 2022

Choose a reason for hiding this comment

pedrorrivero Dec 11, 2022

Choose a reason for hiding this comment

nonhermitian commented Dec 11, 2022

pedrorrivero commented Dec 11, 2022

pedrorrivero commented Dec 11, 2022 • edited Loading

nonhermitian commented Dec 11, 2022

jrj-d commented Mar 4, 2023

pedrorrivero commented Dec 8, 2022 •

edited

Loading

coveralls commented Dec 9, 2022 •

edited

Loading

nonhermitian commented Dec 11, 2022 •

edited

Loading

pedrorrivero commented Dec 11, 2022 •

edited

Loading

pedrorrivero Dec 11, 2022 •

edited

Loading

pedrorrivero commented Dec 11, 2022 •

edited

Loading