OpenQASM 3 circuit depth function

[ryanhill1]

Write function that takes in OpenQASM 3 string as argument and returns the int circuit depth.

Similar to qasm_depth() but for qasm3 instead of qasm2, and which does not use any external libraries.

[TheGupta2012]

@ryanhill1 , I found that the qasm_depth gives the following error when executed as follows -

In [6]: from qbraid.interface.qbraid_qasm.tools import qasm_depth

In [7]: test_str_2 = """
   ...: OPENQASM 2.0;
   ...: include "qelib1.inc";
   ...: qreg q[2];
   ...: qreg q2[4];
   ...: creg c[2]; 
   ...: cx q[0], q[1];
   ...: cx q[0], q2[2];
   ...: h q[1];
   ...: z q[0];
   ...: """

In [8]: qasm_depth(test_str_2)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[8], line 1
----> 1 qasm_depth(test_str_2)

File ~/Desktop/college/quantum/Unitary Fund/Unitary-Hack/qBraid/qbraid/interface/qbraid_qasm/tools.py:73, in qasm_depth(qasmstr)
     70 matches = set(map(int, re.findall(r"q\[(\d+)\]", s)))
     72 # Calculate max depth among the qubits in the current line.
---> 73 max_depth = max(counts_dict[f"q[{i}]"] for i in matches)
     75 # Update depths for all qubits in the current line.
     76 for i in matches:

ValueError: max() arg is an empty sequence

I feel some of the assumptions used in qasm_depth aren't correct -

1. Parsing line by line and looking for qubit arguments with register name as q isn't the right approach. A register may have a name other than q too.
2. Incrementing the count pertaining to a qubit, whenever it is encountered as an argument may be incorrect. This is because of custom gate definitions.

[ryanhill1]

@TheGupta2012 Thank's for pointing this out!

1. I agree that parsing for q is not the right approach. This accounts for most cases, but like you mentioned, the qubits can be named anything, not necessarily q. So we'll want to adapt the function to get the qubit names and use that in the search.

2. I think that incrementing the count pertaining to a qubit is the best approach. In the function, before entering the loop to start counting, we exclude any lines that define custom gate definitions (i.e. lines that start with "gate") so that we don't miscount:

qBraid/qbraid/interface/qbraid_qasm/tools.py

Line 82 in a572428

if s.strip() and not s.startswith(("OPENQASM", "include", "qreg", "gate", "//"))

But there may be other edge cases where qubit names are mentioned that are not currently excluded. So we can definitely look into that more as well.

[ryanhill1]

@TheGupta2012 Following up on this, I added a new qasm3 depth test that uses an alternate qubit syntax:

qBraid/qbraid/interface/qbraid_qasm/tests/test_qasm_utils.py

Line 72 in 6bffe51

def test_qasm3_depth_alternate_qubit_syntax():

It currently fails, so is being skipped. But all OpenQASM 3 generated from Amazon Braket circuits (as of v1.54.1) use this new qubit syntax. So they are a good test case. E.g.

from braket.circuits.serialization import IRType

from qbraid.interface import random_circuit
from qbraid.interface.qbraid_qasm.tools import qasm3_depth

circuit = random_circuit("braket")
qasm_str = circuit.to_ir(IRType.OPENQASM).source

assert qasm3_depth(qasm_str) == circuit.depth

[ryanhill1]

@TheGupta2012 I've updated the qasm_depth() function to account for all edge cases I could find in https://arxiv.org/abs/1707.03429, see test cases. The implementation can definitely be improved, but seems to be working. Regardless, the updated qasm_depth function should at least now provide a decent outline for re-implementing qasm3_depth() without qiskit dependency. If you're still interested, I'll leave that one to you!

[TheGupta2012]

Thanks @ryanhill1 for the updates! I was working on the contiguous qasm issue and will pick this up now.