Operation: interface for QuantumCircuit operations

[jakelishman]

I'm hoping to give us a place to keep notes from meetings, and a place to discuss asynchronously/offline on this proposed new interface. For the first pass, I've tried to write up my understanding of what's been discussed so far, but feel free to challenge my interpretations on those - that's what this is here for.

Other people who have been very involved in this discussion previously:

• @mtreinish
• @kdk
• @alexanderivrii
• @eliarbel

and some people who I think are also invested and may want to comment on the process:

• @ShellyGarion
• @ajavadia
• @ikkoham
• @1ucian0

[alexanderivrii]

@jakelishman, many thanks for taking the discussion on the Operation interface to a completely new level. We have been also thinking about this with @eliarbel and @ShellyGarion, and here are some additional thoughts and questions.

We agree that we do not want Operations to carry around their definitions. Does it mean that we also want to remove definitions for all of the already existing gates (including the basic gates, such as Hadamards)? We can probably store these definitions in the equivalence library, if they are not there already.

Regarding the transpilation process. I am in favor of having a special transpiler pass for each Operation type, very similarly to UnitarySynthesis transpiler pass for unitaries. So, we would have a LinearSynthesis transpiler pass (we have it already, but it does not support parameters such as coupling_map and is not Target-aware), CliffordSynthesis, MCXSynthesis, and so on. Or maybe we can have a single transpiler pass that can take care of all of the different Operations, but such that we can also specify which types of Operations to synthesize and which not to. (Of course, at the end we want the transpiler to synthesize all Operations, but when making intermediate decisions we may only want to synthesize a subset of the types). I also like the plugin capability offered by UnitarySynthesis and think that it would also benefit these special transpiler passes. This ties well with @jakelishman's point:

Researchers will be able to more easily "plug in" their own synthesis methods for higher-order objects at transpilation run time.

The suggested interface also means that Operations are not required to have a to_operator or to_matrix methods, I don't know if this might become problematic.

To better understand the difference between parameter_spec and state: something like rotation angles for rotation gates are considered parameters, while something like destabilizer/stabilizer table for Cliffords would be considered state. Is this understanding correct?

Implementation-wise, the proof-of-concept 7966 on adding Cliffords to QuantumCircuits also required Operations to support broadcasting, condition and _directive, none of which we want in the API. So we will need to handle each of these somehow in the clean implementation of the Operation class.

[mtreinish]

This LGTM, the proposal seems straightforward and matches up with my memory of discussions on this topic. Qiskit/qiskit#7966 is starting the implementation here by adding the base class operation class and the required parameters of name and num_qubits. After that merges we can work on expanding the class definition with the parameter spec (which I assume will involve #26) and the state (which I'll need to write a design doc for) fields. I'm not sure if we want to resolve the questions before merging this. At least questions 2 and 3 have clear answering to me.

[mtreinish]

For me I think it makes the most sense to have classical operations be based on the same base class. We can specialize on top of it if there are stricter requirements, but having a common class for all operations makes working with circuits internally a lot easier I think. Is thing a operation, if so we can use it in a circuit? Then for things consuming circuits at a low level (like qpy) know how to work with the base element in the circuit.

[mtreinish]

I think just the number of qubits the operation acts on directly. If a synthesis method requires an ancilla, it's the responsibility of the synthesis method to know that check and either fallback to some other synthesis method or error appropriately if it can't work.

[jakelishman]

I'll merge and close this, given it's already landed in Terra.

[jakelishman]

Whoops, pressed close by accident. I don't have merge power on this repo, as it turns out.