Parameterised circuits and gradients (for VQE and QAOA)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- backend-api-design, machine-learning
Direzione di ricerca
Start by reading the circuit instruction and matrix construction code, then trace how gate fusion and expectation evaluation work; the issue does not name specific files or tests. Compare adjoint differentiation and parameter-shift behavior against the requested examples, including the special rules for crz and u. Done means parameter rebinding avoids Python re-recording and gradients are available for the stated observables.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What you want to do
expectation() already gives VQE/QAOA energies, but an optimiser loop has to rebuild the whole
circuit for every parameter set and estimate gradients by finite differences. Those are slow and
inaccurate, especially on the 32-bit GPU.
Implementation notes
- Store the parameter index in the instruction and build the matrix at run time. Gate fusion has to
happen after the parameters are bound. - Adjoint differentiation is the efficient default: one forward pass plus one backward pass,
holding about three state vectors, for all parameters at once. - Parameter-shift as an alternative that works with shots. The two-term rule (±π/2) is valid for
rx, ry, rz, p and cp. crz has generator eigenvalues {0, ±½} and needs the four-term rule, and
ushould be differentiated through its three angles separately. - Rebinding parameters must not re-record the circuit from Python.
What it could look like
theta = qsengine.Parameter("theta")
qc = qsengine.QuantumCircuit(2)
qc.ry(0, theta)
qc.cx(0, 1)
qc.expectation("ZZ", params={"theta": 0.4})
qc.gradient(["ZZ", "XX"], coeffs=[1.0, 0.5], params={"theta": 0.4}) # -> {"theta": dE/dtheta}
Contributing
- I would like to open a pull request for this (see CONTRIBUTING.md).
- Lingua principale
- Rust
- Stelle
- 1
- Fork
- 0
- Merge medio
- 12m
- PR unite (30g)
- 4
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di kaiwave/qsengine
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Fold long circuit drawingsApertaenhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Tutte le issue di kaiwave/qsengine
Issue simili
-
bug order-flow studies ui
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
userFRM/egui-charts#2417 ·
I maintainer di solito rispondono entro 1 giorno
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay liveForse già presa @ragelfundionctrumnar l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
UCS-Care-Group/mailcraft#862 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
smoltcp-rs/smoltcp#1243 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno