3
$\begingroup$

On some backends, measuring the same expected value twice to the same classical register always leaves that classical register in the "1" state. I don't know if these results will hold over time, but when I ran the following code the outcome was striking.

OPENQASM 2.0;
include "qelib1.inc";

qreg q[2];
creg c[1];

measure q[1] -> c[0];
measure q[0] -> c[0];

This program should always produce "0" in a simulator and generally produce "0" in a real device. Instead, the results are:

Always/Mostly "0"

  • ibmq_qasm_simulator
  • ibmq_essex
  • ibmq_burlington

Always "1"

  • ibmqx2
  • ibmq_16_melbourne
  • ibmq_ourense
  • ibmq_vigo

As a programmer, I think writes should be independent and the last write should win unless I explicitly allow some kind of quantum fuzziness.

$\endgroup$
  • $\begingroup$ What is a number of shots you used? In case of one shot, it is possible that qubits were spontaneusly excited. $\endgroup$ – Martin Vesely Dec 27 '19 at 5:10
  • $\begingroup$ I used 8192 for all my tests. The "always" results were 8192 out of 8192 shots. $\endgroup$ – balios Dec 27 '19 at 5:24
  • $\begingroup$ I tried to repeat your experiment on IBM Ourense and Melbourne and I got same results, i.e. 1 in 100 %. Then I changed measurement of qubit $q_1$ to register $c_1$ and I got 00 with probability 96.765 % and 98.645 % on Ourense and Melbourne, respectively. These results are along with expectations. So, it seems that there is something wrong with measuring different qubits to one classical register. By the way, what is a point of your code? It seems that you rewerite measuring of $q_1$ by measuring $q_0$. $\endgroup$ – Martin Vesely Dec 27 '19 at 5:47
  • $\begingroup$ I would like to ask somebody from IBM on this forum to check this problem or put more comment on this. $\endgroup$ – Martin Vesely Dec 27 '19 at 5:49
3
$\begingroup$

Your expectation here is correct. c[0] should be 0 (well, modulo some small readout errors). The difference between backends is just due to a software bug on some of them. This will get fixed, thanks for reporting.

As an aside, it is important to note that on current IBM devices, there is a constraint that all measurements are done simultaneously. So both qubits are measured and the state of q[0] and q[1] are determined independently and simultaneously. Then the first value will get written to c[0] followed by the second value. So the final result you see should be the state of q[0] in your program. (I just wanted to clarify that the readouts are not serialized here, but the classical write operations are).

| improve this answer | |
$\endgroup$
  • $\begingroup$ I'm interested in whether the correlation occurs when the value is simultaneously read or when it is simultaneously written. Is it possible to distinguish? $\endgroup$ – balios Dec 27 '19 at 7:22
  • $\begingroup$ In other words, would writing to the same register have any effect on the timing of the measurement side? $\endgroup$ – balios Dec 27 '19 at 7:38
  • $\begingroup$ Actually I updated my answer. There is no race condition here. c[0] should be 0. $\endgroup$ – Ali Javadi Dec 27 '19 at 15:42
  • $\begingroup$ The behavior is different today. Still wrong and bizarre, but not completely consistent with yesterday's tests. Did IBM do any updates today? $\endgroup$ – balios Dec 28 '19 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.