You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
Consider a scenario where a user has some qubits and writes a boolean expression over inline measurements:
The expression short-circuits, so if
measure(a)
isTrue
thenb
andc
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:
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])
andall_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.The text was updated successfully, but these errors were encountered: