GPU numerical accuracy: compensated sums, norm-aware results, optional f64
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- backend, performance
Research direction
Start with qubit_probability.wgsl, src/backend.rs around measure_qubit, and src/pauli.rs to trace probability and expectation calculations. Check how shaders are compiled and how the GPU adapter requests features before assessing the optional f64 path. Done means branch renormalisation uses each branch's measured norm, expectation values account for state norm, and f64 remains optional on supported adapters.
Written by the indexing model from the issue text.
Description
What you want to do
The GPU backend works in f32. Three things make its error bigger than it needs to be:
qubit_probability.wgsladds up to about 32 thousand terms per thread one after another in f32
(at 30 qubits), andmeasure_qubit(src/backend.rs:153) renormalises by 1/√p from that sum.
Errors add up over many mid-circuit measurements in one shot.- The outcome-0 branch is scaled by 1/√(1 − p1), which is only right if the state's norm is
exactly 1. Pauli::expectation(src/pauli.rs) assumes ‖ψ‖ = 1 and does not divide by the norm, so norm
drift becomes a bias in the expectation value.
Implementation notes
- Use Kahan (compensated) summation in each thread's loop in
qubit_probability.wgsl. Return both
the probability of 1 and the total norm from the same pass, and renormalise each branch by its
own sum. - Divide expectation values by Σ|a|², which is a cheap extra sum in the same loop.
- f64: request
wgpu::Features::SHADER_F64when the adapter offers it and compile a second
shader. Most consumer GPUs run f64 at 1/16–1/64 of f32 speed, so it should only be opt-in.
What it could look like
No API change for 1–3. Optionally `backend="gpu64"` on adapters that support `SHADER_F64`.
Contributing
- I would like to open a pull request for this (see CONTRIBUTING.md).
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 12m
- Merged PRs (30d)
- 4
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from kaiwave/qsengine
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
All issues in kaiwave/qsengine
Similar issues
-
bug order-flow studies ui
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
userFRM/egui-charts#2417 ·
Maintainers usually reply within 1 day
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay livePossibly taken @ragelfundionctrumnar claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
UCS-Care-Group/mailcraft#862 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
smoltcp-rs/smoltcp#1243 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day