Emit a cirq.Circuit from a squin kernel

[david-pl]

There's still quite a few things to do here:

• Some of the operator statements (e.g. Kron) don't have a 1:1 mapping to a cirq gate. They probably need a "runtime", since they are easy enough to apply to qubits. Alternatively, we could use custom gates in cirq, but I'm not much of a fan.
• Methods for the noise statements are still missing.
• There is some very hacky stuff I'm doing right now in order to obtain the BlockArguments and ReturnValues in the frame for nested kernels. There's probably a better way to do this, but I don't know how (yet).

[david-pl]

@Roger-luo @weinbe58 do you know how I can properly get the BlockArguments and ReturnValues here? The SSA values are there, but the keys are different in the frame, so I resorted to some not so nice loops & checks.

[weinbe58]

Right now this will basically be the same as inlining the subroutine as you have it here.

I would either just error here and use inlining pass before running emit or think about how to lower a subroutine to a CircuitOperation

[Roger-luo]

why do we handle multiple blocks here? there is only one block? otherwise there will be some sort of control flows which I don't think Cirq supports anyways?

[david-pl]

@weinbe58:

Right now this will basically be the same as inlining the subroutine as you have it here.

Kind of, but there's an important distinction: the result is wrapped as a CircuitOperation and added as a subcircuit.

or think about how to lower a subroutine to a CircuitOperation

Well, isn't this how you would do that? In the end, you need to emit another circuit from the subroutine somehow and then add it to the "parent" circuit. So, at some point we just need to step into the subroutine. That is sort of like inlining, but how else would you do it?

I don't see an alternative way to emit a CircuitOperation. We could probably clean up the way I'm passing in arguments and getting the return value, but I'm not sure how. Do you have an idea?

@Roger-luo:

why do we handle multiple blocks here?

Oversight on my part, I'm now throwing an error if there's more than a single block.

[github-actions]

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
8787	7701	88%	0%	🟢

New Files

File	Coverage	Status
src/bloqade/squin/cirq/emit/emit_circuit.py	98%	🟢
src/bloqade/squin/cirq/emit/op.py	100%	🟢
src/bloqade/squin/cirq/emit/qubit.py	93%	🟢
src/bloqade/squin/cirq/emit/runtime.py	94%	🟢
TOTAL	96%	🟢

Modified Files

File	Coverage	Status
src/bloqade/squin/cirq/_init_.py	92%	🟢
TOTAL	92%	🟢

updated for commit: 96955e7 by action🐍

[codecov]

Codecov Report

Attention: Patch coverage is 95.79580% with 14 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/bloqade/squin/cirq/emit/runtime.py	93.98%	8 Missing ⚠️
src/bloqade/squin/cirq/emit/qubit.py	92.85%	3 Missing ⚠️
src/bloqade/squin/cirq/__init__.py	83.33%	2 Missing ⚠️
src/bloqade/squin/cirq/emit/emit_circuit.py	98.46%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[david-pl]

This is pretty much complete for now.

One thing that is left is to implement the methods for the noise statements, but I'd leave that to another PR since this one is already quite big as it is.
Unfortunately, it looks like we can't use the nice StochasticUnitaryChannel rewrite due to the structure of the noise channels supported by cirq. That is, unless we construct a custom noise model for that or something similar (@weinbe58 ?).
Otherwise, we'll just have to map all the noise channels we can (i.e. the ones supported by cirq) by implementing specific methods.

[weinbe58]

This is pretty much complete for now.

One thing that is left is to implement the methods for the noise statements, but I'd leave that to another PR since this one is already quite big as it is. Unfortunately, it looks like we can't use the nice StochasticUnitaryChannel rewrite due to the structure of the noise channels supported by cirq. That is, unless we construct a custom noise model for that or something similar (@weinbe58 ?). Otherwise, we'll just have to map all the noise channels we can (i.e. the ones supported by cirq) by implementing specific methods.

Actually the StochasticUnitaryChannel was taken from cirq directly. They have a _mixture_ method of any noise channel that is a probabilistic unitary. This method returns a tuple of all the unitary gate operators and probabilities that are coming from noise channel object.

[david-pl]

Actually the StochasticUnitaryChannel was taken from cirq directly.

@weinbe58 if I understand correctly, this only supports randomly choosing from a set of pauli operators. Are multi-qubit PauliChannels not supported in cirq?

[cduck]

@david-pl I don't know but Cirq supports user-defined gates with any Kraus operator so any user could define their own multi-qubit Pauli channel if it's not already defined.

[david-pl]

Moved discussion on noise to separate issue #317