Keeping track of qubits you've measured

[mpharrigan]

@JiahaoYao wanted to take a circuit where we were measuring 1 of the qubits to a case where we're measuring all of the qubits. Sounds like there should be an obvious one way to do this? I wrote the following in response, reproduced here so that others may 1) use this advice or 2) think about why there's no idiomatic way of doing this. cc #4144

Use cirq.measure(*qubits) instead of cirq.measure(q) for q in qubits (where qubits is a list). Now the results will have a 2d numpy array where the second axis is the qubit index in the order they were listed in qubits

You still need to save a mapping between the qubit and the index. One way of doing this is a dictionary {q: i for i, q in enumerate(qubits)}. Since you can always do this on the fly, I prefer just saving the qubits ordered list alongside my circuit so I can make this "mapping" on the fly

Some people use sorted(circuit.all_qubits()) as an implicit qubit ordering everywhere, but I worry this can introduce subtle bugs if you forget to sort your qubits sometimes or e.g. qubits have different sort order after you place your circuit onto a device. I prefer having an explicit qubits list.

Some people like using cirq.measure(q, key=str(q)) for q in qubits and parsing the stringy qubit key. This feels dirty and precludes lots of numpy tricks, e.g. zz_parity = np.sum(bitstrings[:, [i0, i1]], axis=1) % 2

[maffoo]

This is the kind of stuff we deal with all the time at the hardware level, keeping track of what data for each key corresponds to what qubits, so I have some thoughts in this area.

Note that we have a find_measurements helper function in cirq_google to extract information about all measurements in a circuit: https://github.com/quantumlib/Cirq/blob/master/cirq-google/cirq_google/api/v2/results.py#L58. It returns a list of MeasureInfo dataclasses, one for each measurement, that include the measured qubits. It's a bit specialized for google devices, e.g. using cirq.GridQubit instead of cirq.Qid, but in general it's helpful to extract this kind of info from a circuit to help interpret results.

(Aside: One problem I always run into with this kind of analysis is I'd like to be able to compute some property of a circuit, e.g. find info about measurements, and then cache the result on the circuit so I don't accidentally redo the computation. This is harder than it ought to be because circuits are mutable. Having a generic way to cache such analyses and then invalidate them if the circuit is mutated would be useful.)

We could have cirq.Result include some of this information, such as storing the qubits along with the data for each measure key, though if we remove the uniqueness constraint keys as proposed in #4274 it could be that each "instance" of a particular key in a circuit measures different qubits, which would complicate the tracking of what data corresponds to what qubits.

[maffoo]

Not sure I really addressed your question, though. I agree with cirq.measure(*qubits) and keeping track of the qubit order, so maybe the one thing we might consider is including some kind of "measurement descriptor" in cirq.Result so if you save results you don't have to separately keep track of the qubit order.

[mpharrigan]

I should also add cirq.measure(*qubits) keeps all your measure operation in one moment, which is really important.

[dstrain115]

Cirq cync requests an update from @dabacon whether this should be accepted.

[dabacon]

I think storing information about the qubits that are measured on Result seems like a good idea. I think when we've talked about this in the past, it was always pointed out that you could keep track of this yourself, but this seems like a lot of ugly code to have to write.

[daxfohl]

The simulators don't currently track what measurements correspond to what qubits. But I was planning to add this in the near future anyway so that we can support qudits in integer expressions in classical control: if we have cirq.measure(some_qudits, key='mkey'), cirq.X(q0).if('mkey > 20'), then we need to retain at least the shape of the qudits we measured so that we can calculate the int from the dits.

Once that's done we should be able to pass that info into Result easily enough.

[daxfohl]

Unassigning myself but this should be fairly doable now. All the data is stored in the simulation TrialResult class, and just needs passed into the Result class. It might require breaking change to SimulatesSamples._run return type. That currently just returns raw data. If we can have it return the collection of TrialResults instead, then those could be passed into ResultDict to satisfy this requirement. Note qsim would be affected as well.

[95-martin-orion]

All the data is stored in the simulation TrialResult class, and just needs passed into the Result class.

The data is stored in the optional final_step_result field, which is only available to SimulatesIntermediateStates simulators. Since there's no guarantee that a SimulatesSamples simulators implements intermediate states (qsim doesn't, for one) we can't use it here - or at least not in a generic way that covers all simulators.

[daxfohl]

Could we override SimulatesSamples.run_sweep_iter in SimulatorBase? Anything that inherits from SimulatorBase should have this final_step_result field hydrated. Thus SimulatorBase.run_sweep_iter should be able to return Results that have the qubit information (either a new Result subclass, or add the functionality to ResultDict). Then we can revert SimulatesSamples.run_sweep_iter back to expecting a 2D array, which would fix the qsim (and any others) integration.

[95-martin-orion]

I don't think modifying SimulatorBase is sufficient to resolve this problem, as it's not extensible to external simulators. RE use of 2D arrays, I've opened #5014 with a fairly lightweight fix.