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
Ultimately, it is good to have a clifford simulator in tc, but there are more to consider since the scope and nature of a stabilizer simulator are very different from a general simulator.
The features we require include (from high to low):
We implicitly assume the features like gate application, extract the stabilizer state representation and sampling (but making a circuit with named gates and sample from it is far from enough (actually of very little use...))
entanglement entropy calculation
multiple-qubit random Clifford gate support
direct manipulation on stabilizers, clifford maps, etc.
trace to subsystem on a stabilizer state to get a sub stabilizer
In the meanwhile, we hope the simulator is as fast as possible.
Usage and Impact
The use cases include: measurement induced phase transition and random circuit research (high priority), quantum error correction (low priority), hybrid ansatz with Clifford and general part (medium priority), simulator backend for CDR method (medium priority), large scale simulation and benchmark on quantum algorithms and mitigation schemes (medium priority).
The general interface is of course tc.StabilizerCircuit(n) with gates application (the subtle part is about random Clifford gate: how to represent and implement them).
Backward compatibility
Try inherit from AbstractCircuit, but even this approach has some challenges as in stabilizer case, many gates are easy to direct represented by the Clifford map instead of the specific gate decomposition as native gate set, which is conflict with the minimal IR we have now in AbstractCircuit
Related Work
QuantumClifford.jl is an ideal package with basically all features that we need, but it is written in Julia, leaving the integration with TC a pain.
In Python world, Stim is said to be fast but the doc are spare and the feature we required are basically all missing, the package is more suitable for qec and not random circuit investigation unless a lots of work to build relevant feature in tc. (Even EE on stabilizer state is a pain: https://quantumcomputing.stackexchange.com/questions/16718/measuring-entanglement-entropy-using-a-stabilizer-circuit-simulator)
PyClifford has some of the required features and can serve as one option for the integration, but the efficiency is not benchmarked.
Implementation
Ideally, we would like to incorporate another package for Clifford simulation as the backend instead of reinventing all wheels again. But as we mentioned before, there are many challenges to fuse the stabilizer backend into our general framework since quantum circuit is not as simple as only one measurement shots interface (this is barely what qiskit does) when it comes to the numerical investigation. The good news is that, due to the discrete nature of stabilizer circuit, we will lose AD/JIT/VMAP anyway, so we feel ok to directly reuse other package to simulate.
A quick fix on random gate issue could be a specific API on StabilizerCircuit class with no IR involved, i.e. c.random_gate(0, 1, 2), but _qir not record it. c.stabilizer_state() will get the stabilizer to manipulate in the original backend package. The measurement API require some thought, afterall, we now have measure, sample, post_select, cond_measure for a general circuit, how and which to migrate require some efforts
Alternatives
References
The text was updated successfully, but these errors were encountered:
TEP - Stabilizer simulator
Author
@refraction-ray
Status
Draft
Created
2023-07-07
Abstract
Motivation and Scope
Ultimately, it is good to have a clifford simulator in tc, but there are more to consider since the scope and nature of a stabilizer simulator are very different from a general simulator.
The features we require include (from high to low):
In the meanwhile, we hope the simulator is as fast as possible.
Usage and Impact
The use cases include: measurement induced phase transition and random circuit research (high priority), quantum error correction (low priority), hybrid ansatz with Clifford and general part (medium priority), simulator backend for CDR method (medium priority), large scale simulation and benchmark on quantum algorithms and mitigation schemes (medium priority).
The general interface is of course
tc.StabilizerCircuit(n)
with gates application (the subtle part is about random Clifford gate: how to represent and implement them).Backward compatibility
Try inherit from
AbstractCircuit
, but even this approach has some challenges as in stabilizer case, many gates are easy to direct represented by the Clifford map instead of the specific gate decomposition as native gate set, which is conflict with the minimal IR we have now inAbstractCircuit
Related Work
QuantumClifford.jl is an ideal package with basically all features that we need, but it is written in Julia, leaving the integration with TC a pain.
In Python world, Stim is said to be fast but the doc are spare and the feature we required are basically all missing, the package is more suitable for qec and not random circuit investigation unless a lots of work to build relevant feature in tc. (Even EE on stabilizer state is a pain: https://quantumcomputing.stackexchange.com/questions/16718/measuring-entanglement-entropy-using-a-stabilizer-circuit-simulator)
PyClifford has some of the required features and can serve as one option for the integration, but the efficiency is not benchmarked.
Implementation
Ideally, we would like to incorporate another package for Clifford simulation as the backend instead of reinventing all wheels again. But as we mentioned before, there are many challenges to fuse the stabilizer backend into our general framework since quantum circuit is not as simple as only one measurement shots interface (this is barely what qiskit does) when it comes to the numerical investigation. The good news is that, due to the discrete nature of stabilizer circuit, we will lose AD/JIT/VMAP anyway, so we feel ok to directly reuse other package to simulate.
A quick fix on random gate issue could be a specific API on StabilizerCircuit class with no IR involved, i.e.
c.random_gate(0, 1, 2)
, but_qir
not record it.c.stabilizer_state()
will get the stabilizer to manipulate in the original backend package. The measurement API require some thought, afterall, we now havemeasure
,sample
,post_select
,cond_measure
for a general circuit, how and which to migrate require some effortsAlternatives
References
The text was updated successfully, but these errors were encountered: