Support parametrized circuits in other frontends beyond Cirq

[andreamari]

After parametrized gates (with symbolic parameters) of Cirq circuits will be supported (#939 and #911), it would be good to support parametrized gates of other circuit types too. This issue is to keep track of what we currently support in Mitiq:

• [x] Cirq parametrized circuits.
• [ ] Qiskit parametrized circuits.
• [ ] PyQuil parametrized circuits.
• [ ] Braket parametrized circuits.
• [ ] PennyLane parametrized circuits.

[alejomonbar]

Can I work on this one? @rmlarose @andreamari

[purva-thakre]

Hi @alejomonbar I am already working on parameterized circuits for Qiskit.. You could work on the other 3 if you want to.

[purva-thakre]

@rmlarose @andreamari Would it be ok to use a different version of QASM as support for only parametrized circuits in qiskit ?

v2.0 has issues with adding parametrized circuits when the parameters are unbounded. I was working to define a function with bounded parameters as defined on page 5 of v2.0 paper which would be then used by mitiq's conversion functions.

But I came across v3.0 paper and it does seem to support unbounded parameters. I haven't read the paper in detail to be able to understand if additional changes would have to be made in mitiq_qiskit for non-parametrized circuits.

[andreamari]

Hi @purva-thakre,

we currently use the conversion functions that are built in Cirq and, probably, they are not compatible with QASM 3. But feel free to try if you think it can work. Ideally, if both Cirq and Qiskit are compatible (or will be compatible soon) with QASM 3, this seems the ideal solution to me.

Regarding the approach of page 5 of v2.0 paper : they seem to define custom gates to map parametrized gates to QASM. This could work, however I am not sure it will be easy to convert from QASM to Cirq. I.e., I think that Cirq function circuit_from_qasm will fail to recognize them.

[purva-thakre]

@andreamari I think for now I will use QASM 2 and make changes for unbounded parameters later when Cirq's converters become compatible with QASM 3.

Considering the goal is to allow parametrized circuits in Qiskit, I thought it would be easy to do Qiskit --> QASM --> Cirq.

The main issue is related to QASM 2 causing issues with an unbounded parameter in a Qiskit circuit and my solution would be to either force the user to provide the bounds for the circuit parameter or use a default general range of parameters provided in above linked QASM 2 paper.

I haven't looked too deeply into how Cirq's QASM parser works but I did attempt to convert an example circuit in Qiskit's documentation into a Cirq circuit using from_qasm.

If I attempt to use print(qc.qasm())in the Qiskit example, there's an error due to QASM 2

QasmError: 'Cannot represent circuits with unbound parameters in OpenQASM 2.'

But if the theta parameter is bounded as shown here, then use of print(circuits[-1].qasm()) will give me

OPENQASM 2.0;
include "qelib1.inc";
qreg q[5];
creg c[1];
h q[0];
cx q[0],q[1];
cx q[1],q[2];
cx q[2],q[3];
cx q[3],q[4];
barrier q[0],q[1],q[2],q[3],q[4];
rz(2*pi) q[0];
rz(2*pi) q[1];
rz(2*pi) q[2];
rz(2*pi) q[3];
rz(2*pi) q[4];
barrier q[0],q[1],q[2],q[3],q[4];
cx q[3],q[4];
cx q[2],q[3];
cx q[1],q[2];
cx q[0],q[1];
h q[0];
measure q[0] -> c[0];

Thus, using from_qasm(circuits[-1].qasm()) does give the desired circuit (but with bounded parameters)

q_0: ───H───@───Rz(2π)──────────────────────────────────────────@───H───M('c_0')───
            │                                                   │
q_1: ───────X───@────────Rz(2π)─────────────────────────────@───X──────────────────
                │                                           │
q_2: ───────────X────────@────────Rz(2π)────────────────@───X──────────────────────
                         │                              │
q_3: ────────────────────X────────@────────Rz(2π)───@───X──────────────────────────
                                  │                 │
q_4: ─────────────────────────────X────────Rz(2π)───X──────────────────────────────

To summarize, a possible solution for now could be chosen as :

1. Force user to provide bounds of a parametrized gate or have some default values for the parameters. The default parameter values for anything beyond single-qubit gates could be an issue. So, the user will have to be forced to provide a bound for n-qubit (n>1) gates in Mitiq.
2. Try to see if the version of QASM could be changed in the header when going from Qiskit --> QASM and QASM --> to Cirq.
3. Keep this issue open until both Cirq and Qiskit are compatible with QASM3

Edit : I will try to work on 2 + try to understand if QASM 2 and 3 could be used simultaneously

[andreamari]

@purva-thakre, if I understand correctly, "binding" a parameter corresponds to replacing it with a numerical value or with a list of different numerical values producing a list of different circuits with different numerical parameters. So after biding, one doesn't have symbolic parameters anymore. I think that, in this case, the existing workflow is already compatible with Mitiq and there is nothing new to add. Please correct me if I am wrong.

What we currently miss, is the possibility of applying Mitiq directly to a circuit with symbolic parameters. In this case, your third option is probably a wise choice.

[purva-thakre]

after biding, one doesn't have symbolic parameters anymore

Please correct me if I am wrong

Yeah, that was my problem with what I was trying to do because providing values for the parameters defeats the purpose of a parametrized gate. No, you are not wrong that this workflow is already compatible with Mitiq.

~~I thought of 3 possibilities to fix the issue, 1 was the most disliked, not sure if 2 is possible and 3 seems to be the most likely possibility.~~

~~I found this answer on StackExchange which links a qiskit issue that might have a way around qasm2's problem with parametrized circuits. Not sure how it works exactly but it does have some code lines for symbolic parameters. If this fails then will re-attempt this after qsm3 is released.~~

Will attempt this after Cirq and Qiskit are both compatible with qasm3

[github-actions[bot]]

This issue had no activity for 2 months, and will be closed in one week unless there is new activity. Cheers!

[aakif-akhtar]

Hi, is anyone doing this task currently? I need this feature in my project if no one is doing it I can take it up.

[andreamari]

@aakif-akhtar, sure!

Do you have in mind a particular solution? If I remember correctly, this isn't as easy as it seems. So we may need to agree on the solution before implementing it.

Would you like to focus on a specific frontend (Qiskit, Braket, ...) ?

[aakif-akhtar]

@andreamari I would first like to take Qiskit, and my current approach is as follows: Every circuit in qiskit must be bounded before passing it to the backend and our problem with mitiq lies in folding gates , after passing the parameterized gate I would attempt to bind the parameters to the circuit inside the folding gates function of mitiq, so that now this circuit can be used by mitiq.

[andreamari]

Hi @aakif-akhtar, I am not sure about this solution. See this this previous discussion https://github.com/unitaryfund/mitiq/issues/941#issuecomment-966396760

What we are looking for is the possibility of directly applying mitiq (e.g. folding functions) to gates with symbolic parameters. I know this may not be easy/possible to achieve but, in principle, this is the scope of this issue.

[aakif-akhtar]

Hi @andreamari give me this weekend and i will try to see if a direct application is possible as that will be easier to use for me too.