GPU numerical accuracy: compensated sums, norm-aware results, optional f64
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- rust
- Área
- backend, performance
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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).
- Lenguaje dominante
- Rust
- Estrellas
- 1
- Forks
- 0
- Merge medio
- 12 min
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de kaiwave/qsengine
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
bug good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Fold long circuit drawingsAbiertoenhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
Todos los issues de kaiwave/qsengine
Issues similares
-
bug order-flow studies ui
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
userFRM/egui-charts#2417 ·
Los mantenedores suelen responder en 1 día
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay livePosiblemente ocupada @ragelfundionctrumnar la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
UCS-Care-Group/mailcraft#862 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
smoltcp-rs/smoltcp#1243 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día