tket
tket copied to clipboard
ECR gate not properly supported in QASM export
The following simple code snippet
from pytket import Circuit
from pytket.qasm import circuit_to_qasm_str
circuit = Circuit(2)
circuit.ECR(0, 1)
print(circuit_to_qasm_str(circuit))
Unexpectedly (to me) raises an exception
Traceback (most recent call last):
File "<...>/test.py", line 7, in <module>
print(circuit_to_qasm_str(circuit))
File "<...>/venv/lib/python3.10/site-packages/pytket/qasm/qasm.py", line 811, in circuit_to_qasm_str
circuit_to_qasm_io(circ, buffer, header=header)
File "<...>/venv/lib/python3.10/site-packages/pytket/qasm/qasm.py", line 1076, in circuit_to_qasm_io
raise QASMUnsupportedError(
pytket.qasm.qasm.QASMUnsupportedError: Gate of type ecr is not defined in header qelib1.inc
While it is, of course, true that the ecr
gate is not part of the standard qelib1.inc
, I would have expected tket
to provide a corresponding QASM gate definition. Specifically, I would have expected the above script to produce something like
OPENQASM 2.0;
include "qelib1.inc";
gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(param0) q1; cx q0,q1; h q1; }
gate ecr q0,q1 { rzx(pi/4) q0,q1; x q0; rzx(-pi/4) q0,q1; }
qreg q[2];
ecr q[0],q[1];
similar to how qiskit
itself dumps such circuits.
pytket version: 1.5.2 os: Ubuntu 22.04 python version: 3.10.6
Thanks for the suggestion. I can imagine use cases that require the QASM generation to be more flexible. Perhaps we can add a flag to disable checking whether the gates are in the specified header lib. Any thoughts @cqc-alec ?
Thanks for the suggestion. I can imagine use cases that require the QASM generation to be more flexible. Perhaps we can add a flag to disable checking whether the gates are in the specified header lib. Any thoughts @cqc-alec ?
I'm not sure. Is what qiskit produces valid qasm? (It doesn't seem to include any extra headers.) We want the output of the converter to be readable by general qasm parsers.
Qiskit provides custom gate definitions just as in the example above for any gate that is not in qelib1
(and any general QASM parser should be able to read those). So the following script
from qiskit import QuantumCircuit
qc = QuantumCircuit(2)
qc.ecr(0, 1)
print(qc.qasm())
currently produces
OPENQASM 2.0;
include "qelib1.inc";
gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(-pi/4) q1; cx q0,q1; h q1; }
gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(pi/4) q1; cx q0,q1; h q1; }
gate ecr q0,q1 { rzx(pi/4) q0,q1; x q0; rzx(-pi/4) q0,q1; }
qreg q[2];
ecr q[0],q[1];
Note that the Qiskit output isn't correct at the moment (it contains a duplicate definition of the rzx
gate and the parameter in each of them is fixed
). This is due to Qiskit having all kinds of troubles with parameterised gates in the QASM export. See https://github.com/Qiskit/qiskit-terra/issues/7335 for reference.
The proper output that qiskit would strive for is the one shown in the first post, i.e.,
OPENQASM 2.0;
include "qelib1.inc";
gate rzx(param0) q0,q1 { h q1; cx q0,q1; rz(param0) q1; cx q0,q1; h q1; }
gate ecr q0,q1 { rzx(pi/4) q0,q1; x q0; rzx(-pi/4) q0,q1; }
qreg q[2];
ecr q[0],q[1];
Ah I see, so the suggestion is to add gate definitions to the generated qasm. Yes that sounds like it would be useful!
Hello @burgholzer, with pull request https://github.com/CQCL/tket/pull/612 our qasm generating methods will now auto generate gate definitions for any pytket
gates with an OpType
not supported by the default qasm header.
Awesome! Many thanks. I'll surely check this out soon 👍🏻