Dax Fohl

@tanujkhattar @MichaelBroughton this seems like a big pre 1.0 item if we ever want to do it.

xref https://github.com/quantumlib/Cirq/pull/4631, the classical control PR for Cirq.

This seems to be happening in the factor when the measurement gate is encountered. https://github.com/quantumlib/cirq/blob/8953eebe05e2510d798356dfd9fc2d5ba922cfe9/cirq-core/cirq/linalg/transformations.py#L636 likely needs to renormalize after getting the partial traces. For now, OP can create the...

Note reverting #4300 fixes this, though that implementation is still incorrectly (and worsely) normalized in other cases. I think the pre-#4300 implementation should be faster since it calculates both factors...

Ran some tests and the newer implementation using partial_trace is faster than the old implementation. Will push a PR that restabilizes the DM by trace after factoring.

I created #5902 that improves the situation here a fair amount. Curious to see what more can be done!

Also I'd have to imagine that `einsum` has the optimizations from #5902. So `targeted_left_multiply` may already be optimal for sparse operator matrices. Edit: I take it back, or at least...

For posterity and since the code is rather tricky, #5905 is also a large boost when the matrix is one-hot, which is the case for many Kraus components such as...

@viathor I accidentally linked this to close instead of #5900. The most important channels have been addressed but IDK if you wanted to keep this open to investigate the others.

If you create a list of the qubits and then create a circuit from the list, that should give _much_ faster construction times than appending to the circuit one-by-one.