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:
[x] (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. #83
[x] Adding gate predecessors/successors API to QCir and starting to support ID-based access to instructions. #89
[x] 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. #94
[x] Unify QCirGate with device::Operation and duostra::Gate. #94
[x] Starts to add different inheritance of Operation. #98 #100 #101
[x] (breaking change) Retiring QCirGate as the interface to the gate's predecessors and successors. #98
[x] update printing functions for QCir #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.
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
GateRotationCategoryof swap---exposesget_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
QuantumCircuitcontains a list ofCircuitInstructions.A
CircuitInstructionis composed of an Operation and its operands. For example, acx q[0], q[1]; instruction is composed of the operationcxand operandq[0], q[1];An
Operationcan be a quantum gate, measurements, barriers, etc.Note that in the above, none of the above hierarchy maintains the gate connectivity explicitly because
QuantumCircuitalways sorts itsCircuitInstructionin the topological order. Qiskit also has another class calledDAGCircuitfor applications that require further knowledge of the connections.Ours
Currently, our abstraction is as follows:
A
QCircontains a list ofQCirGates.A
QCirGateis an instruction and knows its connection to the predecessors/successors.A
GateTyperepresents a quantum gate and is a helper class in instantiating QCirGate. Note that eachQCirGatedoes not own aGateTypebut takes the latter’s information into the former’s members.The Remedy
I propose to
QCir.QCirGatewill become local to its pertinentQCirand 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.Operationclass that represents an operation and can be owned by aQCirGate.QCirGatetoInstructionto better reflect its role in the code base.More specifically, here’s a plan of how we would achieve that:
QCirand starting to support ID-based access to instructions. #89QCirGateas an instruction abstraction, add an Operation as an operation instruction, and repurpose the current GateType as a legacy gate type inheritingOperation. #94QCirGatewithdevice::Operationandduostra::Gate. #94Operation. #98 #100 #101QCirGateas the interface to the gate's predecessors and successors. #98QCir#98QCirGatetoInstruction.QCirGate*as the accessor to all gates in theQCir.