amazon-braket-sdk-python
amazon-braket-sdk-python copied to clipboard
Do not hardcode symbol transformation
Describe the bug In the unicode diagram builder, control modifiers and swap gate symbols are transformed via a hardcoded piece of code like here. It would be better to avoid transforming symbols into other new symbols.
Random thoughts
- (Neg)Control modifiers are implemented in two ways which does not help to design a solution without hardcoded the mapping. These two ways are:
- multiple target qubits and including
"C"in ascii_symbols - adding qubits in
controlFor some gates (likeCNot), the first qubit of the control register is transferred to the target register:CNot(target=0, control=1)->CNot(target=[0,1])as the CNot is a 2-qubit gate. For these gates, nothing indicates that they are essentially controlled gates, which means that one can only figure it out by searching the character "C" in ascii_symbols. This is currently done at the very end of the current implementation. On the other side, any gate can be controlled by the state of other qubits. These qubits are tracked in acontrol_qubitsset, which is inspected earlier to define the scope of the gate (i.e[min(full_qubit_register):max(full_qubit_register)]to build the connection map.
- multiple target qubits and including
Ideas for a solution
- Long-term: redefine the gate interface such that for instance CNot is Ctrl @ X and consequently
CNot.ascii_symbols = ["X"]. This would limit the way to define control qubits to a single possibility. - Shorter-term: Using a GateSymbol representation class with inheritance for the specific cases like NoGate (untouched qubits between
min(full_qubit_register)andmax(full_qubit_register)), Swap gate and control modifier. Here is an unfinished attempt. These classes can be specific toAsciiDiagramBuilderandUnicodeDiagramBuilder. This would be a way to associate (qubit, symbol, connections) for each moment but still requires to browse through the ascii_symbol table to search for control modifiers.