Add technique composability guide to core concepts (closes #2288)#2970
Add technique composability guide to core concepts (closes #2288)#2970Rachel-Eva wants to merge 2 commits into
Conversation
natestemen
left a comment
natestemen
left a comment
There was a problem hiding this comment.
Thanks for kicking this off! I really like the discussion about technique interfaces and the comments about backfiring. I think the examples are unnecessary since that's what the examples gallery is for. I think we can replace those with links to tutorials that showcase the stacking options.
I think this page would also benefit from a table towards the top of the page that would allow someone to get an idea of which techniques can/cannot stack. I know this depends on whether an observable is being used and maybe a few other factors, but starting with two cases
- executor returns bitstrings, and
- executor returns expectation values
would be a great start.
| - how ZNE acts as the outer framework in most compositions, | ||
| - why different techniques have different interfaces and what that means for composing them, | ||
| - worked examples for REM + ZNE, DDD + ZNE, PT + ZNE, and a three-technique combination. | ||
|
|
There was a problem hiding this comment.
This is a larger comment for this entire page, but also here: Let's not focus too heavily on ZNE here, even though our tutorial gallery does lean towards ZNE. This page should be about stacking two arbitrary techniques that are available in mitiq.
| **REM is different.** REM specifically targets errors that happen during *measurement* — the | ||
| readout stage. To correct those errors, it needs the raw measurement data (bitstrings) before | ||
| they are turned into an average. This is why an REM executor must return `MeasurementResult`, | ||
| not `float`. The mitigation math (applying the inverse confusion matrix) runs directly on those | ||
| raw counts. Only after that correction does REM hand a usable result upstream. |
There was a problem hiding this comment.
The statement that bitstrings are being averaged is incorrect. Please read the REM user guide: https://mitiq.readthedocs.io/en/stable/guide/rem-5-theory.html
| | Technique | `mitigate_executor`? | Executor must return | Returns | | ||
| |-----------|:--------------------:|----------------------|---------| | ||
| | ZNE | yes | `float` or `QuantumResult` + observable | `float` | | ||
| | REM | yes | `MeasurementResult` | `MeasurementResult` | | ||
| | DDD | yes | `float` or `QuantumResult` + observable | `float` | | ||
| | PT | no — manual loop | any | averaged `float` | |
There was a problem hiding this comment.
What about the many other techniques?
| **PT has no `mitigate_executor` at all.** This is structural, not an oversight. Most techniques | ||
| follow a 1-to-1 or 1-to-N circuit flow that still ends in a single expectation value — | ||
| `mitigate_executor` handles that pattern automatically. PT is N-to-1: it requires generating | ||
| many random circuit variants, running all of them, and averaging the results to cancel out | ||
| coherent noise. That averaging loop cannot be hidden behind a single executor call, so PT always | ||
| requires a manual loop using `zne.construct_circuits` and `pt.generate_pauli_twirl_variants`. |
There was a problem hiding this comment.
I don't think this is true. pt.generate_pauli_twirl_variants acts in the same way that xyz.construct_circuits does (1 to N).
| extrapolating back to zero. That assumption only holds cleanly for incoherent, Markovian noise | ||
| that scales predictably with circuit depth. For coherent noise (systematic over-rotations), gate | ||
| folding amplifies the coherent errors unfavourably, and ZNE can make results worse than doing | ||
| nothing at all. The `pt_zne` tutorial documents this directly. The fix is to apply PT first to |
There was a problem hiding this comment.
Linking to the tutorial will be helpful for the reader if you're referencing it.
| channel more symmetric but cannot actually decouple the system from the environment — meaning | ||
| the benefit is limited at best. On top of that, gate-level DDD is an approximation of the ideal | ||
| pulse-level technique, and some backends internally reschedule gates in ways that can undermine | ||
| the sequences. The theory page is explicit: "it may happen that, for some sequences, the final |
There was a problem hiding this comment.
Link to the theory page missing.
| | Noise type | ZNE | LRE | REM | DDD | PT | PEC | CDR | | ||
| |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | ||
| | Incoherent gate noise (depolarizing, amplitude damping) | Y | Y | N | partial | partial | Y | Y | | ||
| | Coherent gate noise (over-rotations) | partial | partial | N | N | Y | Y | Y | | ||
| | Time-correlated (non-Markovian) noise | partial | partial | N | Y | partial | N | N | | ||
| | Readout / measurement errors | N | N | Y | N | N | N | N | | ||
| | Crosstalk (idle-qubit errors) | N | N | N | Y | partial | N | N | |
There was a problem hiding this comment.
This is a nice table! Replacing Y with ✅ and N` with ❌ might make this a bit easier to skim at a glance.
| | Readout / measurement errors | N | N | Y | N | N | N | N | | ||
| | Crosstalk (idle-qubit errors) | N | N | N | Y | partial | N | N | | ||
|
|
||
| To understand the table, it helps to know a bit about each technique's properties: |
There was a problem hiding this comment.
This is not a page to explain how these techniques work. Lets keep it focused to composition.
|
Thanks for the feedback, I've made changes to the file. Let me know if this version is better. |
2 participants
Description
Closes #2288
Adds a new
composing-techniques.mdpage to the Core Concepts section of the user guide.The page covers:
License
Before opening the PR, please ensure you have completed the following where appropriate.