5 ms·
> your goals (e.g. compilation into realistic gates) are very different from the goals of these language designers (study of abstract structure of quantum algor
by Strilanc 5y ago
> your goals (e.g. compilation into realistic gates) are very different from the goals of these language designers (study of abstract structure of quantum algorithms)
But the abstract structure of quantum algorithms is all about the carefully orchestrated structure within entanglement, not whether entanglement is present. Also, even just considering whether entanglement is present, the rules that they use in the language are far too weak. They basically amount to "if you do a two qubit operation it might be entangled". How is something like that ever going to help verify, for example, that already-allocated-but-currently-unused qubits being used as dirty ancillae (as in [1]) are being correctly restored (e.g. disentangled from the context where they were temporarily used)? It's just going to say "I dunno, they touched, they might be entangled". But I know they touched and might be entangled. I'm looking for a more gradual transition from "I applied no operations therefore everything is fine" to "I need to spin up a Turing complete simulator and do runtime analysis".
> if teleportation was "built-in" for the language, then the language would be useless for anything but "numerics"
I didn't mean to suggest hard-coding teleportation. What I was picturing is that the language would understand the stabilizer formalism [2], which is powerful enough to encode many quantum protocols but restricted enough to guarantee efficient classical analysis. Teleportation is a special case of things efficiently handled by the stabilizer formalism.
1: https://arxiv.org/abs/1611.07995 https://arxiv.org/abs/1611.07995
2: https://arxiv.org/abs/quant-ph/9705052 https://arxiv.org/abs/quant-ph/9705052
- krastanov 5y agoYup, I concur, it is a bit too weak currently, but my answer would be that I am really excited even for such baby steps, because it is so much more interesting of an approach than the (I would say) boring high-performance simulation libraries from google/ibm/other quantum startups/etc.
- Strilanc 5y agoHahaha, this is quite funny to me since I write some of those boring high performance simulation libraries. In my defense I'll note that e.g. Stim [1] isn't just fast; it has correctness tools. For example, stim circuits can include DETECTOR annotations that state which measurement sets should be deterministic. It's not a type system, but oh boy does verifying that information help a lot when debugging error correction circuits. I have other examples, but I digress. I would love if someone could make a type system that gave me similar benefits and scaled to complete algorithms. But a verbose system for keeping track of who-touched-who just isn't it. 1: https://quantum-journal.org/papers/q-2021-07-06-497/ https://quantum-journal.org/papers/q-2021-07-06-497/ or https://github.com/quantumlib/Stim/ https://github.com/quantumlib/Stim/
- krastanov 5y agoYup, I am a big fan of Stim, and work on similar tools in Julia. It is awesome to be able to run 1Gqubit Pauli multiplication in a few milliseconds, however I feel it is reasonable to call this "boring" high-performance libraries given how "fortran-ie" they still feel. Even if the application of these libraries is not boring at all (I have seen what Stim can do).
- Strilanc 5y agoAh, you're that krastanov. https://github.com/Krastanov/QuantumClifford.jl/commit/aafd5806fdace9be04be4a72cf135e398d8d092b https://github.com/Krastanov/QuantumClifford.jl/commit/aafd5... Hey, when everyone else is falling back to "oh we just simulate the hard cases to verify them", making simulation faster is making verification better.
- krastanov 5y agoYou are right. And, practically, I probably will be using Stim much more in the next few years than this particular toy language. Same as you, I hope this toy language leads to more research in useful type theory for quantum algos.