Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Short circuiting behaviour can be confusing #594

Open
jake-arkinstall opened this issue Oct 24, 2024 · 1 comment
Open

Short circuiting behaviour can be confusing #594

jake-arkinstall opened this issue Oct 24, 2024 · 1 comment

Comments

@jake-arkinstall
Copy link
Contributor

Consider a scenario where a user has some qubits and writes a boolean expression over inline measurements:

x = measure(a) or measure(b) or measure(c)

The expression short-circuits, so if measure(a) is True then b and c are not measured. The user would certainly want those left unmeasured to be discarded, as they have purposefully written an expression that loses information about which qubit measured True.

What currently happens is an error - e.g. "c is not used in all control paths". In this context this error can be confusing, because short circuiting is implicit.

The user is thus faced with two main options without diverting to a helper function:

  • measure all qubits, then use their results in an expression (which may be more expensive than measuring some and discarding others)
  • nested ifs and elses that gets increasingly involved as the number of qubits increases.

I'd like to know if there's a way of improving this.

A low hanging fruit option includes the introduction of any_measure(qs: list[qubit]) and all_measure(qs: list[qubit]), which discards remaining qubits after an early decision can be made. This doesn't generalise well, but it may be sufficient.

I don't know anywhere near enough about how the internals work, but if there's a way of modifying visit_BoolOp to detect measurements and clean up short-circuits with discards, that would possibly be the ideal situation. I can't envision a scenario where a user would do this and still want the qubit to be hanging around.

@mark-koch
Copy link
Collaborator

I think the easiest work around for now is to use & and | instead of and and or which doesn't short-circuit:

x = measure(a) | measure(b) | measure(c)

I'm sceptical about special-casing measure since the same problem applies for every function that consumes a linear argument (say, a nested struct or array containing qubits).

Instead of any_measure(qs) it would nicer if we could do any(measure(q) for q in qs) where any doesn't short circuit if the generator is linear. This should generalise nicely and is easier to detect than fiddling with the CFG to detect short-circuited measurements

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants