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.

Improve this question
$\endgroup$
4
  • $\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, 2019 at 5:10
  • $\begingroup$ I used 8192 for all my tests. The "always" results were 8192 out of 8192 shots. $\endgroup$
    – balios
    Dec 27, 2019 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, 2019 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, 2019 at 5:49

1 Answer 1

Reset to default
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$
4
  • $\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, 2019 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, 2019 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, 2019 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, 2019 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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