4 ms·
Oh, yes, you can of course use a static or runtime type system to try to keep track of that kind of thing. The tricky thing is that measurement isn't always as
by Strilanc 10y ago
Oh, yes, you can of course use a static or runtime type system to try to keep track of that kind of thing.
The tricky thing is that measurement isn't always associated with a single qubit. For example, consider:
if q1 != q2:
apply H to q1
This code will cause some decoherence, because we need q1's original value to uncompute the condition but we changed it. But that decoherence isn't specifically associated with just q1, it will also hit q2 because the thing we decohered was the parity between the two.
Now you could detect this happening at runtime, sometimes. The ancilla holding the condition value fails to uncompute consistently, so it will sometimes end up ON. The runtime could notice that ON ancilla and warn you that an ancilla failed to uncompute, but there could be many many actions in between that ancilla being computed and uncomputed. It's hard to figure out which action or combination of actions is the problem, and it's hard to figure out what exactly was decohered. Plus this check is only probabilistic; decoherence is a property of the program not the ancilla's final state. Decoherence still happened if the ancilla ended up OFF but could have ended up ON.
- Turing_Machine 10y agoThanks. I'm going to take a while to process that. :-)
- db48x 10y agoStatic types are the qrusty way to do it. Runtime bookkeeping is wasteful.