Bloqs non-unitary gates

[mpharrigan]

The bloqs data structure can represent non-unitary gates. For example: you can create a "measure" bloq that has one incoming wire and zero outgoing wires. This probably isn't ideal for interacting with protocols.

• Do we need classical registers/soquets to let classical data flow through the compute graph? How would this work with tensor simulation? Can we replace measurement with e.g. cnotting to a newly allocated qubit and tracing out the original one?
• quimb simulation is for state vectors. We need to support density matrices
• Cirq lets you "run" a circuit and gather samples from measurement gates. I propose this is out-of-scope for now, since it doesn't jive with quimb / tensor networks.

xref #445 #448

[daxfohl]

Cirq has a defer_measurements transformer that takes a circuit with measurements and classical controls, and transforms it into a quantum one. It takes things like noisy measurements, repeated measurements, sympy conditions, and qudits into account. There's no such thing as purely classical logic in Cirq, but if there was, it could be added to the transformer easily too. The one thing it doesn't support is classically-controlled loops since the circuit has to be deterministically unrollable, but I don't think that's even possible in theory.

I considered adding functionality to the density matrix simulator to do this at simulation time, rather than requiring the user to transform the circuit in advance, but it ended up just being messy and not worth it. In particular you'd have to be able to add qubits dynamically to the simulation with this approach, and at the time this would break the whole pipeline. Possibly now with ancilla support, this would be easier.

While doing this it occurred to me that there's probably a more space-efficient representation than a density matrix. I believe the classical bits should be representable by 2^N states, so the full state should be 4^n_qubit*2^n_cbit, plus the classical parts can be float instead of complex. This would be useful since cbits are cheaper in the real world too. That said, IDK what the actual representation or the state transition algebra would look like, or whether it could be implemented efficiently in numpy. May be an interesting project for someone.

https://github.com/quantumlib/Cirq/blame/main/cirq-core/cirq/transformers/measurement_transformers.py#L65

[daxfohl]

Oh, actually I did do a prototype of doing this at runtime. Completely forgot.

quantumlib/Cirq#6040 (comment)

[daxfohl]

And I guess one advantage of doing this at simulation time is that you don't have to fully unroll the loops in advance. So in a situation where the loop can't be unrolled but does deterministically halt, like do { X(q); measure(q, key) } until key, you could fully calculate the output density matrix. IDK how useful that would be in practice though.

[daxfohl]

One more thing, given the deferred measurements principle, you may not necessarily need to trace out the original, and thus not need a density matrix. You'd have to be able to account for ancillas representing the classical bits, but the state vector of that whole system should be enough to represent everything you need to know.

Unless there are limitations to the deferred measurements principle that cause it not to apply in some situations. (In which case the deferred measurements transformer in Cirq probably needs fixed too--it intentionally does not add a dephase op after measurements, so that the resulting circuit could run in the state vector simulator).

[mpharrigan]

I would think that -- more often than not -- if you're measuring or deleting information, you'd want the density matrix rather than a statevector with a bunch of extra indices you thought you deleted.

[daxfohl]

Yeah, but you might be able to peel that off at the very end, which would allow you to run the simulation as a state vector including the ancillas representing measurement, then get the partial trace of the actual qubits without those ancillas as the final step. It'd be more efficient than maintaining a density matrix throughout the entire simulation, and allow quimb to continue doing most of the work.

That's assuming the approach is logically correct of course, which I'm not 100% certain.

[mpharrigan]

One of the benefits of using something like quimb is that the tensor contraction ordering is distinct from the tensor network construction. Better yet: it will try to find a good contraction ordering automatically. As such, it's best to keep things as factored as possible when constructing the tensor network. If you're dealing with a lot of bits that get traced out (deleted), it's probably a lot more efficient to get rid of them as quickly as possible.

[mpharrigan]

Closing as redundant with the linked roadmap items.