More versatile if_else conditions in qiskit

[AndyLiuin]

What should we add?

Hi so I've been trying to put error correction gadget in my circuit,

1. e.g. for the Fault-tolerant Steane EC, we need to measure the syndrome of a logical 0 ancilla, which is a 7-bit outcome, this is then multiplied by the parity check matrix (in this case a 3x7 matrix). This would result in a 3-bit result and this error syndrome indicates subsequent operations applied. I might be mistaken, but this is not possible with current if_test statement, the type being compared is "ClassicalRegister". I would like to request for functions allowing more comparison such as the above or if_test((clbits1, clbits2)) for testing if two classical outcomes are the same. (I found in Cirq such test function allows Sympy expression so I think this should also be doable in qiskit ... )

2. I want to do more operations after if_test: I wish to achieve one more round of different error correction once a previous EC circuit flags an error. This is also not allowed after if_test, an error shows up qiskit.exceptions.QiskitError: 'Cannot convert condition in circuit with multiple classical registers to instruction'

Thanks if you can help support the above functionality, it would potentially allow people to actually implement a fault-tolerant circuit. Currently all we're doing is to test the threshold of certain codes, but cannot put these gadgets into circuits.

[AndyLiuin]

I found that maybe I can run a circuit after if_test/if_else by passing the EC circuit in parameter "true_body", but it doesn't seem to work, anyone can help?

[jakelishman]

Let me start by saying that we're absolutely working on expanding Qiskit's ability to represent classical operations, on Aer's ability to simulate such instructions, and in our hardware being able to perform such mixed quantum/classical computation. The expansion of these "dynamic circuits" capabilities is a big part of our plans for Qiskit in the coming year.

For point 1: adding a representation in Terra is only a small part of this effort. We're also committed to having general classical processing on IBM hardware, and in the fast Aer simulator, and it might be frustrating for users if Terra can represent a lot more is possible than even on our simulators. It's more work for us on Aer to add support for classical processing than for Cirq because all our simulation is done in compiled languages away from the Python runtime, so it's not practical (nor efficient) to call out to Sympy. We also intend to support a much stronger type system in classical values as part of our joint work with the other parts of the OpenQASM committee on OpenQASM 3, which Sympy isn't intended to represent.

For point 2: this sounds like you're trying to do qc.append(gadget), which attempts to add the "gadget" as a single opaque instruction onto the circuit. For now (again, while we're expanding classical processing), you might have more success using QuantumCircuit.compose, which inlines one circuit into another. This allows for much more flexibility with mapping registers between, and seems to be a little bit more like what you intend.

[jakelishman]

With the merging of the epic #10239, I think we can consider this issue closed for the purposes of its original post. Please feel free to re-open or create a new issue if there's more to discuss.