Hacker News new | past | comments | ask | show | jobs | submit login

By "caught you peeking" I meant something reminiscent of the "taint" mechanism you see in languages like Perl and Ruby. Once the qubit was measured, it would be marked so, and the compiler or interpreter would complain if you attempted to use it as if it were unmeasured.



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.


Static types are the qrusty way to do it. Runtime bookkeeping is wasteful.


Thanks. I'm going to take a while to process that. :-)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: