Fix qpy support for Annotated Operations

[alexanderivrii]

Summary

This PR is built on top of #11495 and adds QPY support for annotated operations, addressing the other part of #11088.

(Update: removed a question on serializing/deserializing floating-point numbers which is relevant for storing power for PowerModifier; changed qpy format to store double).

Details and comments

I feel that I have cut a few corners in the implementation, suggestions for improvement are welcome.

First, instead of creating separate types for storing inverse modifiers, power modifiers and control modifiers, I am storing a "generic" modifier which includes the type (i.e. inverse, power or control), and num_ctrls, ctrl_state and power.

Second, I am handling annotated operations as "custom instructions" (similar to ControlledGates) which already provides a convenient method to store/load the "base operation". The list of modifiers is stored in instruction_params.

[qiskit-bot]

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

• @Qiskit/terra-core
• @mtreinish
• @nkanazawa1989

[coveralls]

Pull Request Test Coverage Report for Build 7744276070

• -4 of 57 (92.98%) changed or added relevant lines in 4 files are covered.
• 18 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.02%) to 89.32%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/qpy/binary_io/circuits.py	44	46	95.65%
qiskit/qpy/type_keys.py	5	7	71.43%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	6	90.68%
crates/qasm2/src/parse.rs	12	96.23%

Totals
Change from base Build 7744260861:	-0.02%
Covered Lines:	60188
Relevant Lines:	67385

---

💛 - Coveralls

[mtreinish]

I think this requires bumping the QPY version to 11 as this is a new struct to represent the modifiers. If someone tried to load a file using this with 0.45 which uses the same qpy version this would result in an error when the loader encounters the annotated operation (actually the new type key would trigger this too).

[alexanderivrii]

I see, thanks.

Does this mean that I need to change this line

if version >= 5 and type_key == type_keys.CircuitInstruction.ANNOTATED_OPERATION:

to version >= 11 and ... or does this require more drastic changes? In addition, is this related to #11644?

[mtreinish]

You'll need to change that condition, also bump https://github.com/Qiskit/qiskit/blob/main/qiskit/qpy/common.py#L23 to 11, and also update the format documentation to describe what's new in version 11. I have another PR #11646 that actually is adding version 11 already, you can use this as a model. The two will merge conflict but we can handle that as there will only be version 11 in this release (there is only one format version for each qiskit release).

#11644 will have implications for this, as we'll need to error if someone uses an annotated operation and the version < 11 (this was something I didn't have to worry about in #11646)

[mtreinish]

This LGTM, just a couple comments inline. The other thing I think would be good to add here is a backwards compatibility test in https://github.com/Qiskit/qiskit/blob/main/test/qpy_compat/test_qpy.py that verifies annotated ops can be represented between versions into the future.

[mtreinish]

Do we not export AnnotatedOperation from qiskit.circuit? I feel like it should be there as it is a public interface. If we are wouldn't this line pick it up as an attribute of the circuit module?

[alexanderivrii]

Indeed, that was an omission on my part. 77d044d exports this together with the modifiers. This also removes the need to check the name in the if above.

[mtreinish]

LGTM, thanks for the update