Repository navigation
[qec] Share Stim QUBIT_COORDS emission in the emitter module - #538
Conversation
Both builders call stim_emit::emit_qubit_coords. Lattice surgery still walks blocks in workload order. Measure lines and closing detectors stay in the builders. Checked-in Stim gold stays byte-identical. Refs #473 Co-authored-by: Arnab Ghosh <ag2583@cornell.edu>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| /// | ||
| /// Single-block memory passes one block. Lattice surgery calls this once per | ||
| /// block, in workload order. Pairs stop at the shorter slice, matching `zip`. | ||
| pub(crate) fn emit_qubit_coords(out: &mut String, atoms: &[PhysicalAtomId], coords: &[(i32, i32)]) { |
There was a problem hiding this comment.
Approve. I would merge this slice on 586f21a.
Both builders call stim_emit::emit_qubit_coords for QUBIT_COORDS(x, y) id. The helper keeps caller order and stops at the shorter slice, the same zip as before. Single-block memory passes one block. Lattice surgery still loops expanded.blocks in workload order and calls the helper once per block.
Measure lines and closing detectors are not in this diff; they stay in the builders. The checked-in Stim gold is not in the diff. The new function has no unwrap or expect. qubit_coords_keep_caller_order locks [4, 0] against [(1, 2), (3, 4)] and the one-pair shorter slice.
Title, body, and the commit mention the issue only as Refs #473. They do not use fixes/closes/resolves, and they do not say the issue stays open. This slice does not move measure lines or closing detectors.
This branch was successfully deployed
2 participants
Summary
QUBIT_COORDSline emission intostim_emit::emit_qubit_coords.Refs #473
Test plan
cargo test -p quon_qecincludingstim_structure_matches_checked_in_goldcargo clippy -p quon_qec --all-targets -- -D warningsnpx @taskless/cli@0.9.0 checkon the changed files