QCir Refactor

[joshmtlau]

The Problem

Currently, the qcir package is hard to use mainly because it fails to account for the variability of different types of gates. For example, we can’t model a matrix or a boolean oracle to a gate;

Also, some gates expose inappropriate interfaces; the SWAP gate---currently implemented through a GateRotationCategory of swap---exposes get_phase(), and before a previous refactoring, a T gate exposes set_phase()---which causes problems in identifying gate type.

Comparing with Qiskit’s Abstraction

Qiskit’s

I’ve investigated how Qiskit structures their qk.QuantumCircuit. Roughly speaking, their abstraction is as follows:

A QuantumCircuit contains a list of CircuitInstructions.

A CircuitInstruction is composed of an Operation and its operands. For example, a cx q[0], q[1]; instruction is composed of the operation cx and operand q[0], q[1];

An Operation can be a quantum gate, measurements, barriers, etc.

Note that in the above, none of the above hierarchy maintains the gate connectivity explicitly because QuantumCircuit always sorts its CircuitInstruction in the topological order. Qiskit also has another class called DAGCircuit for applications that require further knowledge of the connections.

Ours

Currently, our abstraction is as follows:

A QCir contains a list of QCirGates.

A QCirGate is an instruction and knows its connection to the predecessors/successors.

A GateType represents a quantum gate and is a helper class in instantiating QCirGate. Note that each QCirGate does not own a GateType but takes the latter’s information into the former’s members.

The Remedy

I propose to

• Hand the knowledge of gate connections over to QCir. QCirGate will become local to its pertinent QCir and is always accessed by its IDs. This should not be too problematic because when we care about predecessors and successors, we often need the whole circuit anyway.
• Add a polymorphic Operation class that represents an operation and can be owned by a QCirGate.
• Maybe rename QCirGate to Instruction to better reflect its role in the code base.

More specifically, here’s a plan of how we would achieve that:

• (breaking change) Reduce rarely used and problematic APIs, such as traversal APIs and get-time APIs, while retaining the project's functionalities. Alternatively, convert them to free functions. Refactor/qcir flexible gate type #83
• Adding gate predecessors/successors API to QCir and starting to support ID-based access to instructions. Refactor/qcir flexible gate type #89
• Repurpose the current QCirGate as an instruction abstraction, add an Operation as an operation instruction, and repurpose the current GateType as a legacy gate type inheriting Operation. 💍 One gate type to rule them all #94
• Unify QCirGate with device::Operation and duostra::Gate. 💍 One gate type to rule them all #94
• Starts to add different inheritance of Operation. Refactor/qcir flexible gate type #98 Refactor/qcir flexible gate type #100 Refactor/qcir flexible gate type #101
• (breaking change) Retiring QCirGate as the interface to the gate's predecessors and successors. Refactor/qcir flexible gate type #98
• update printing functions for QCir Refactor/qcir flexible gate type #98
• To better reflect its role in the code base, maybe rename QCirGate to Instruction.
• (breaking change) Migrate to use ID instead of QCirGate* as the accessor to all gates in the QCir.