Closed inmzhang closed 1 day ago
Sorry for not responding to this for awhile. I took some inspiration from this PR and started iterating on it, and ultimately ended up going in a different direction. Specifically, I added a sinter.Sampler
class and allowed it to go almost anywhere a sinter.Decoder
can currently go, with the understanding that the sampler will take full responsibility for generating samples and producing statistics instead of only handling the decoding. This made fewer changes to the API surface, and fixed a nasty annoyance where not every sampler is compatible with every decoder (or even needs a decoder) but sinter was still asking for a decoder.
Closing as obsoleted by https://github.com/quantumlib/Stim/pull/804
Fixes #682
This issue is related to one of my projects, so I attempted a basic and quick solution. I followed the pattern of
sinter.Decoder
and the implementation between the two should be similar.The sampler has been poorly tested, and there may still be some issues with backward compatibility. However, I would appreciate your initial thoughts, as I'm not sure if this aligns with your design for this issue.