Error Pruning

[drewconnelly-qntm]

Often Logical failures contain a core logical error as well as 'fluff' that can be removed without changing the logical class. Once error logging is done (and maybe visualization too) it would be nice to introduce a pruning routine which takes a set of physical errors and sees if it can remove any (or introduce stabilizers) to reach a lower-weight logical representative. This isn't that good for distance-finding (SAT solving is better) but it does help diagnose what's going wrong when you are debugging a qecc implementation.

[ciaranra]

That sounds super useful! Especially with realistic noise likely injecting a lot of random noise that doesn't contribute to the logical error.

[ciaranra]

If it is just Pauli noise... This would be super easy and almost something we already have with the backwards propagation of noise for DEMs and the "tracked Paulis" we have in PECOS... For non-Paulis and non-static circuits, it could be tricker 🤔

[ciaranra]

Alternatively... If we are using DEMs... We could back prop and associate which DEM error event fired and which physical mechanism contributed to it. The DEM event would connect the physical mechanism to the logical operator 🤔

[drewconnelly-qntm]

@ciaranra

If it is just Pauli noise... This would be super easy and almost something we already have with the backwards propagation of noise for DEMs and the "tracked Paulis" we have in PECOS... For non-Paulis and non-static circuits, it could be tricker 🤔

I think the core idea is even simpler than you are thinking, say we look at your error generation methods, wherever they are, and pull out a set of all the errors you applied / injected into the ideal circuit (the circuit is fixed now in terms of any conditional logic since it is now in the past). We then have this error-set { $e_i$ }, and we just want to (naively) try turning each one off one at a time until we have the smallest error set that still causes a logical error. This still works if the error is non-pauli or conditional since we have the benefit of knowing what happened in hindsight. We can also insert stabilizers / flip multiple errors at once which is a bit trickier but should be ok.

Alternatively... If we are using DEMs... We could back prop and associate which DEM error event fired and which physical mechanism contributed to it. The DEM event would connect the physical mechanism to the logical operator 🤔

Yeah I'd definitely say the best outcome of this sort of thing is taking a large cloud of errors and pulling out the smallest 'fatal' error, and THEN backtracking that to a physical mechanism if we have the type of provenance chain we would need to do that. If DEMs let us do that then that would be super nice.

The error provenance would even let us build up the google-style "blame" bar charts for which fraction of the logical error rate is due to which type of physical error, we could see well what experimentalists should try to optimize and what they should not worry about.