Add AlphaSyndrome measurement strategy (arXiv:2601.12509)

[acasta-yhliu]

This is a local merge request for #421 to make modifications easier.

I've implemented the AlphaSyndrome syndrome measurement scheduler. A few notes:

• Implemented under src/qLDPC/circuits/alphasyndrome.py.
• Implemented test
• Multiprocessing is not introduced. I've encountered OOM because Python would copy the data of the parent process.

Some other things to be checked:

• Copyright information
• Coding style

[acasta-yhliu]

I've moved to a local branch to make changes easier.

uv.lock is removed.

Please check the pyproject.toml when merging.

[perlinm]

I took a pass through alpha_syndrome.py to add comments and simplify data structures somewhat (for example, removing WrapCSS and making TreeNode problem-agnostic).

@acasta-yhliu if you have the time, could you please take one more look through the file to make sure the new version with my changes looks correct? If you approve of the current version, we can merge into main.

[perlinm]

Can you help me understand this reward?

[acasta-yhliu]

The reward in MCTS is the higher the better, so I use $1 / error\ rate$. To avoid division by $0$ we add $1$ to the number of logical errors.

[acasta-yhliu]

I think everything looks fine and clean now.

If you need further help in implementing some features in the qLDPC package, I'm also willing to contribute my effort! I should start practicing how to work with open-source projects now.

[perlinm]

@acasta-yhliu thank you! There was a recent flurry of papers on arXiv right before the QEC2026 submission date, and I believe some of them included some interesting codes that would be nice to add to qLDPC. I intent to look more closely and file issues accordingly.

Regarding this PR, though: can you comment on your attempts to parallelize AlphaSyndrome with multiprocessing? Where/how did you try to parallelize?

My first thought was to parallelize the iterations in AlphaSyndrome._schedule_one_gate, but looking more closely these iterations are sequential: the choice if best_child in each iteration depends on the outcome of previous iterations...

[acasta-yhliu]

Thanks! I'll look at the issues and see what I can contribute.

For parallelization, I tried to parallelize the stim simulation. As you may notice, Python's multiprocessing would make a copy of the MCTS tree when spawning new processes (it really depends on the implementation; it should be shared with the parent process, but sometimes it copies). This is the root cause of many OOMs, and some decoder implementations have a resource management problem when creating multiple instances (particularly mentioned stimbposd). In my experiments, I can work around this by firing processes by invoking new Python interpreters running a specific "decoding" script, and passing the syndromes through inter-process communication. I don't know if this can be done within a Python package? Or there may be a more elegant way to do it.

BTW, sinter also uses multiprocessing, so the same problem is still there.

[perlinm]

I see, so it's really a multiprocessing problem to be solved by sinter. Thanks for clarifying!

[perlinm]

Alright, I think the last thing to do is add an example notebook for AlphaSyndrome, ideally showing better performance than the default syndrome measurement strategy for some code (e.g., Steane code or rectangular surface code).

[perlinm]

I added a tentative example notebook (examples/logical_error_rates/5_alpha_syndrome.ipynb), but the example needs to be fixed. We want an example that shows AlphaSyndrome outperforming the default syndrome measurement strategy.

[perlinm]

@acasta-yhliu maybe you know a nice example to show off in the notebook?