add hypergraph-UF and mwpf decoder in sinter

[yuewuo]

This is a simple adaptation of the mwpf' python package to sinter. Just copied the _decoding_fusion.pyand modify it accordingly to let the decoder consider hyperedges. Tested using thegetting_started.ipynb` and they run decoding without a problem.

I haven't added any test cases for this, since I didn't find a test case for fusion_blossom decoder as well. Please let me know where should I put a basic test case for the new decoders!

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Strilanc]

Thanks for the contribution. Unfortunately, I think there's currently a bit of a showstopper. The timeout behavior needs to be replaced in order for results to be mergeable (and reproduceable) across machines. Otherwise the decoder is ill-behaved in ways that make it dangerous to collect statistics at different times and places while expecting them to be from the same distribution, which is something sinter sort of implicitly assumes.

[Strilanc]

Could these names be more descriptive?

[yuewuo]

A basic performance benchmark using the sinter jobs of getting_started.ipynb (the sinter.collect( block of repetition_code:memory)

• pymatching: 1.7s
• fusion_blossom: 35s
• hypergraph_union_find: 89.5s
• mw_parity_factor: 142.9s

By the way, I had some thoughts on the slow down of fusion_blossom compared to pymatching: it is probably coming from duplicate edges. The current implementation of sinter for fusion_blossom does not deduplicate the edges (and merge them) like pymatching would do internally when calling the add_edge function. I think there could be some functionality outside of pymatching that merges the edges. Do you think this is reasonable?

[Strilanc]

Having duplicate edges could certainly slow things down. Stim already dedupes most errors so there may not be a lot of dupes to start with.

[yuewuo]

Having duplicate edges could certainly slow things down. Stim already dedupes most errors so there may not be a lot of dupes to start with.

Thanks for the insight! Indeed, just printed them out and there are no duplicate edges. I've also tried to reduce the integer weight of the edges, but the decoding time remains almost unchanged. The most probably reason would then because iterating the ndarray in Python instead of in Rust. I'll investigate in this to get a better understanding.

[yuewuo]

Having duplicate edges could certainly slow things down. Stim already dedupes most errors so there may not be a lot of dupes to start with.

Thanks for the insight! Indeed, just printed them out and there are no duplicate edges. I've also tried to reduce the integer weight of the edges, but the decoding time remains almost unchanged. The most probably reason would then because iterating the ndarray in Python instead of in Rust. I'll investigate in this to get a better understanding.

Sorry I made a stupid mistake...... I installed the debug version of the fusion_blossom package which runs for 35s. Once I switch to a release version, it drops to 6.3s. This makes more sense. Similarly for mwpf package. Here is the new result:

• pymatching: 2.3s
• fusion_blossom: 6.3s
• hypergraph_union_find: 9.7s
• mw_parity_factor: 14.0s

[Strilanc]

I moved this to #837 so I could resolve the merge conflicts.