4 ms·
Hahaha, 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 jus
by Strilanc 5y ago
Hahaha, 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.