0
$\begingroup$

I was just wondering what the difference is between the 2 types of implementations one can take in implementing the OBSERVABLE_INCLUDE command. Given any stim.Circuit() we can append the following:

Method 1: circuit.append("OBSERVABLE_INCLUDE", [stim.target_rec(-1)...], 0)

Method 2: circuit.append("OBSERVABLE_INCLUDE", X1 X2 X3..., 0)

The 1st method makes sense to me: We have done a measurement of our data qubits at the end of the run and therefore can see if errors change the given measurement record.

The 2nd method isn't clear to me yet. Do we look at the current Pauli frame to determine if a logical error occurred, i.e., flipped the observable?

What is the use case even for the 1st method if I can easily just add my logical observables by qubit index instead of additionally needing to add a measurement before?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

The 2nd method is more flexible, but is ignored when sampling measurements (such as when using real hardware). It will only yield the correct observable flip values when simulating shots with the detection event sampler.

When sampling with real hardware, the only effect OBSERVABLE_INCLUDE(0) X1 can have is to change how the detector error model's errors are annotated and thereby affect decoding.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Why exactly is the 2nd method not implementable for real hardware? If the 2nd method is really looking at the current Pauli frame of the circuit and therefore can depict if a logical error happened just by looking if the errors in the Pauli frame form a logical observable, why do we need to measure at all? I thought that direct Pauli frame updates are possible on real hardware... Thanks for all the help! $\endgroup$
    – Fabian Spreemann
    Commented Jun 22 at 13:18
  • $\begingroup$ @FabianSpreemann well for starters it violates the Heisenberg uncertainty principle, because it allows you to simultaneously determine information about anti-commuting operators. I think you're confusing applying paulis for extracting information about Paulis. $\endgroup$
    – Craig Gidney
    Commented Jun 22 at 17:45
  • $\begingroup$ I think you misunderstood me, or I was not quite clear enough. I was not referring to the measurement of any real logical observable. Both methods tell us when the logical observable would be flipped if we measured it. The direct measurement would directly see if errors would flip the measurement. Here we also can depict the logical state as we measure the qubits directly. With the 2. method, we track the Pauli frame, where we can see that if we measured the state, it would be flipped (this doesn’t violate Heisenberg). So in principle, we can use both methods in real hardware, right? $\endgroup$
    – Fabian Spreemann
    Commented Jun 22 at 19:38
  • $\begingroup$ But it wouldn’t make any sense to only use the 2. Method. We would know that if we measured the logical observable, we would still need to actually know the state in order to flip it. I.e. the information that we need to flip the state doesn’t really get us that far without actually knowing the state. That’s why we use the 1st implementation in real hardware, and that’s why the 1st method is the only one showing up in the .compile_sampler() function (as it’s based on real measurements). Is my understanding correct, or am I completely lost here? Thanks again for all your support! $\endgroup$
    – Fabian Spreemann
    Commented Jun 22 at 19:44

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.