Fix bug in logic for releasing qubits after joint measurement

[swernli]

To allow release of qubits that have been collapsed by measurement, we mark them with IsMeasured equal to true (see #206). However, joint measurement does not collapse the states of the input qubits and might actually create additional entanglement, so those qubits should not be marked as valid for release.

This change fixes the logic by only marking the input to Measure when it is a single qubit, and adds a test that validates the exception that should be thrown when trying to release qubits after joint measurement.

[anpaz]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[IrinaYatsenko]

What is the exact promise of the release-after-measurement? Is it just "best effort" on the simulator's side or a guarantee that if post-measurement the state isn't a superposition then it's OK to release? Because a joint measurement might collapse a state to one of the basis vectors. For example, if you have a superposition like |00>+|10>, the joint ZZ measurement would collapse it to either |00> or |01>.

[swernli]

The original motivation behind the exception at runtime was to allow the simulator to perform some validation of algorithms. The simulator will always collapse the state of a qubit that is being released (it actually internally performs the measurement to do so). But that may have a side effect on other qubits if the qubit that is reset is still entangled. With the original check, the runtime would throw if a qubit was released that is not exactly in the |0⟩ state, but we did the work to relax that to allow release of any qubit that is either |0⟩ or measured, since measurement means it cannot be entangled. But even there, we didn't consider joint measurement, which would not guarantee the qubit is no longer entangled. With this change, I think we landed at what we originally wanted to do to address #206: qubits that we can reasonably conclude are no longer entangled and are in a well-known basis state are safe to release.

There is actually some good context for the decision and the approach in Aniket's PR, #231, so I'd recommend checking that out for some details from Chris and Andres.

[swernli]

I think I need to close and reopen this to get it the pipelines to rerun...

[swernli]

Oh, never mind. The pipelines not running appears to be an ongoing issue:
https://developercommunity.visualstudio.com/content/problem/1211721/azp-run-does-not-find-associated-pipelines-for-pr.html

[IrinaYatsenko]

The original motivation behind the exception at runtime was to allow the simulator to perform some validation of algorithms.

Do I understand it correctly, that the purpose of the feature is to allow the user omit explicit reset in the cases when the runtime can verifiably prove the qubit being released isn't entangled? I.e. it's OK if the user still has to call Reset explicitly even if a joint measurement might have unentangled the qubit (|00>+|10>+|01> => |00> if ZZ measured Zero) but it's a bug to allow the user omit reset when the qubit is actually entangled, right?

[swernli]

@irinayat-MS Yes, that's correct, and good way to summarize it. The one addition I'd make is that we also allow for what I think of as a "logical reset" ie: calling X when the qubit is known to be in the |1〉 or H when it is known to be in the |+〉 state. I think this is implied by your use of just the word "reset" instead of the operation Reset but I figured it's worth calling out.

[IrinaYatsenko]

lgtm

[cgranade]

The original motivation behind the exception at runtime was to allow the simulator to perform some validation of algorithms.

Do I understand it correctly, that the purpose of the feature is to allow the user omit explicit reset in the cases when the runtime can verifiably prove the qubit being released isn't entangled? I.e. it's OK if the user still has to call Reset explicitly even if a joint measurement might have unentangled the qubit (|00>+|10>+|01> => |00> if ZZ measured Zero) but it's a bug to allow the user omit reset when the qubit is actually entangled, right?

Apologies for re-opening the thread, but I wanted to provide a little bit of clarification if I could. It's entirely possible for two qubits to be entangled with each other, but yet still in a fully deterministic state that allows the compiler to efficiently and automatically reset them. In particular, consider the following snippet:

using ((left, right) = (Qubit(), Qubit()) {
    let xx = Measure([PauliX, PauliX], [left, right]);
    let zz = Measure([PauliZ, PauliZ], [left, right]);
}

At the point of deallocation, the state of [left, right] is guaranteed to be one of the four Bell pairs, conditioned on the values of xx and zz. Using the stabilizer formalism, it's efficient to compute the sequence of operations needed to unprepare each of the four states.

While I don't suggest that we necessarily support that scenario, I find it helpful in separating out the requirement that qubits be unentangled from the requirement that the compiler can efficiently and automatically unprepare a register into the |00…0⟩ state so that they're ready for the next allocation.

[swernli]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[bettinaheim]

@ScottCarda-MS @swernli Looks like monomorphization is throwing on this one; is this fixed or are you on that? I just updated the branch, respawning the build.

[ScottCarda-MS]

@ScottCarda-MS @swernli Looks like monomorphization is throwing on this one; is this fixed or are you on that? I just updated the branch, respawning the build.

Looks like it is an instance of the issue on compiler repo: microsoft/qsharp-compiler#689
There is a PR up for that on the same repo: microsoft/qsharp-compiler#694
Once that is in, it should fix the issue experienced here.

[ScottCarda-MS]

@ScottCarda-MS @swernli Looks like monomorphization is throwing on this one; is this fixed or are you on that? I just updated the branch, respawning the build.

Looks like it is an instance of the issue on compiler repo: microsoft/qsharp-compiler#689
There is a PR up for that on the same repo: microsoft/qsharp-compiler#694
Once that is in, it should fix the issue experienced here.

The PR has been merged in, so once you merged in from main, the issue should be resolved.

[swernli]

Thanks @bettinaheim and @ScottCarda-MS for keeping an eye on this and getting it merged!