search

oqc-community / qat

QAT is a quantum compiler and runtime focused on low-level, just-above-driver integration.
Other
49 stars 11 forks source link

Bugfix: qiskit bitstring ordering #180

Closed lcauser-oqc closed 2 months ago

lcauser-oqc commented 2 months ago

Brought forward a previous pull request to reverse the ordering that qiskit returns the bitstrings.

I have returned the changed tests to their original form (note that the original tests failed while the new tests pass). These tests highlighted another problem: when a QASM script is compiled to a QuantumCircuit using the QiskitBuilder, the ordering of the bitstring can be wrong. For example, the script

OPENQASM 2.0;
include "qelib1.inc";
qreg q[4];
creg b[4];
x q[1];
x q[3];
measure q -> b;

will return the bitstring in the order q_{0} q_{2} q_{1} q_{3}. For the test, this was fixed by just adding a barrier before measurement... I'm not certain if this return order is intended, but if not, we can address it in a separate issue.

lcauser-oqc commented 2 months ago

how would a barrier correct the bit order ?

Great question! In practice, I think it shouldn't? However, this is a problem unique to the QiskitBuilder. Essentially, using QiskitBuilder.measure(qbit) doesn't currently make use of the classical bit where the measurement is stored (although this information is communicated). The current implementation results in the measurements being assigned to the classical register in the order which the measurements are taken.

This shouldn't be a problem for QASM scripts which take measurements of all qubits at the end (or selected qubits in a given order), but the TKET optimisations can change the order of measurements without changing the meaning of the circuit (this is what happens in this test). This results in the Qiskit simulator returning the bit strings in the wrong order (beyond just reversing the order, as we have fixed here). Adding the barrier ensures that all measurements are taken at the end. However, this is just a quick fix to ensure the test works as functioned.

Note that this would also be a problem for specific use cases where a user might want to store the measurement of qubits to a classical register in a non-standard order (e.g. q{0} -> c{2}, q{1} -> c{0} and q{2} -> c{1}).

I have implemented a potential fix for the Qiskit simulator which I will push shortly that essentially keeps track of the order measurements are taken, and which bit the result should be assigned to, and after the simulations are completed, reorders the bitstrings. This will allow the test to work without the barrier. I would like to add a few more tests to ensure it functions as expected.