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
Sparse parity-check matrix support for decoders (#550)
Continuation of [#440](#440).
Closes [#379](#379).
Introduces `cudaq::qec::sparse_binary_matrix` (CSC/CSR, `uint32_t`
indices) as the decoder PCM type, so large PCMs no longer have to be
materialized as a dense `cudaqx::tensor`. The sparse path is wired
through PCM generation, round slicing, decoder construction, and Python
bindings. `sliding_window` canonicalizes once and reads `H.ptr() /
H.indices()` directly per window.
## Breaking changes
- **Decoder constructor** now takes `const sparse_binary_matrix &H`.
Dense `cudaqx::tensor<uint8_t>` callers still compile via implicit
conversion, but the extension-point template changed — **out-of-tree
plugins must be recompiled**.
- **`generate_random_pcm` throws above `k_max_dense_pcm_elements`
(400M)**. Use `generate_random_pcm_sparse` for larger matrices.
- **`single_error_lut_example`** now uses column `qErr` of H directly
instead of XOR-of-other-columns (the old form was only correct when
every row of H had even weight). Example plugin only; production
`single_error_lut` was already correct.
## Follow-up PRs
- Sparse-aware PCM utilities: migrate sort_pcm_columns, simplify_pcm,
reorder_pcm_columns, shuffle_pcm_columns, pcm_extend_to_n_rounds,
pcm_to_sparse_*, pcm_from_sparse_*, and
detector_error_model::canonicalize_for_rounds to sparse_binary_matrix so
the full #379 scale pipeline avoids any dense cudaqx::tensor<uint8_t>
allocation.
- Docs: Sphinx entries for the new type/functions and the 400M dense
cap.
Note to reviewers: Quick context on why it's larger than the ~1000-line
guideline: it's a foundational type-system change rather than an
additive feature. The new sparse_binary_matrix type, the decoder
constructor breaking change, all the plugin updates, the sparse
generator, and the Python bindings all have to land together for the
#379 fix to actually be usable end-to-end. Splitting it would create
intermediate states where the breaking change has landed but users still
can't construct a >50k-mechanism PCM which would mean shipping the API
churn without the benefit.
---------
Signed-off-by: Ben Howe <bhowe@nvidia.com>
Signed-off-by: vedika-saravanan <vsaravanan@nvidia.com>
Signed-off-by: Angela Burton <angelab@nvidia.com>
Co-authored-by: Ben Howe <bhowe@nvidia.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Angela Burton <angelab@nvidia.com>
0 commit comments