qbraid / qbraid-qir Goto Github PK

Feature Description

It was recently brought up that QIR can be used as an input to Microsoft Azure's resource estimation tools. It seems like the current implementation of qbraid-qir does not do a good job of translating cirq into QIR in a way that preserves the resources involved in a quantum algorithm. It should be investigated whether this is something we care about and to what degree users want to do resource estimation from a QIR format.

Proposed Implementation

No response

Add support for converting OpenQASM 3 program which contain subroutines to QIR.

Placeholder test cases: test_subroutines.py

e.g.

OPENQASM 3.0;
include "stdgates.inc";

def apply_h_and_measure(qubit q) -> bit {
    bit result;
    h q;
    measure q -> result;
    return result;
}

qreg q[1];
creg c[1];

c[0] = apply_h_and_measure(q[0]);

openqasm reference for implementing subroutines

Value : $150

Move exception handling to inside of visitor for unsupported operations used try except around convert to callable

Right now, we can not pip install qbraid-qir into the test qir-runner Dockerfile because of this weird bug: qir-alliance/pyqir#267

As an initial workaround, we attempted to create a script get-wheel.sh that downloaded the latest pyqir wheel files directly from github, however, there have been some difficulties with this as well, including trying to make it work programmatically in an OS-agnostic way.

The best solution until the the above linked issue is resolved it to add code to build pyqir from source within the Dockerfile. Instructions on how to do that can be found here: https://www.qir-alliance.org/pyqir/building.html

After adding the steps to build and install pyqir from source, we would like to install qbraid-qir into the container so that we can use it seamlessly along with qir-runner.

Put together one or two Cirq example implementation of Grover's, QPE, or some other small programs that have some type of physical significance, pass them through the QIR converter, simulate using the qir-runner package (available through the test-containers), and determine if the results are consistent with what we would expect. Add some LaTeX/markdown providing some context for the example so that's it's not just raw code. Then we add the notebooks to a new examples folder demonstrating how the package can be used.

Implement classical bits / measurement operations

Now that we've implemented and rolled out a functional Cirq $\rightarrow$ QIR converter, the next step is to demonstrate the project's utility i.e. justify the work we've done with a compelling use-case or application.

There's multiple directions we can take this including but not limited to:

• Resource estimation (#45)
• Running experiments on hardware and/or hybrid simulations (#28)
• Writing a developer's guide that provides a roadmap for building a "high-level quantum package" $\rightarrow$ QIR converter
• Benchmarking compilation times: https://arxiv.org/pdf/2101.11365.pdf

Implement BasicQisVisitor class. In the visit_operation() method, instead of using conditionals to map string gate names to functions, import a dictionary which defines those mappings from opsets.py. See #16

Writing the BasicQisVisitorclass will, by extension, also involve modifying to the _CircuitElement and CirqModule constructs defined in elements.py.

The cirq_to_qir() top-level function is the entry-point into the QIR conversion module(s). Before passing the input Cirq circuit to CirqModule.from_circuit(), we will want to pass it through a pre-processing function that ensures that the circuit is composed only of supported gates and operations. According to supported gate set defined in #16, perform gate decomposition. Ensure that input/output circuit.unitary() are equivalent.

In the future, we will expand this circuit pre-processing function to also account for edge cases like converting Cirq Moments to barriers. Depending on what makes the most sense, some or all of this "pre-processing" logic might be more efficient if defined directly within the CirqModule.from_circuit() method.

implement logic for handling conditional operations based on prior measurements

• https://github.com/qir-alliance/pyqir/blob/26885c9dd74d89e11056c980380bc99f337bb03d/pyqir/pyqir/_native.pyi#L1225-L1242
• https://quantumai.google/reference/python/cirq/ClassicallyControlledOperation

Feature Description

openqasm3 supports the 4gate modifiers -

1. inv @ U : replaces the gate $\mathbf{U}$ with $\mathbf{U^{\dagger}}$.
2. ctrl @ U and negctrl @ U : replaces $\mathbf{U}$ with the controlled and inverted controlled versions of the unitary respectively
3. pow(k) @ U : replaces $\mathbf{U}$ with $\mathbf{U^{k}}$

Implementation (Optional)

The easiest implementation path would be to make a _handle_modifier method.

1. Since pow only adds copies of the gate, it can be delegated to the gate call handling method.
2. Handling inv will depend on whether we have a custom gate definition or a native gate. If a custom gate is called, we would first invert the gate body and recursively apply the inversion function. If a basic gate is encountered(as defined in pyqir._native), apply its inverted equivalent.
3. ctrl would be tricky as we need to check if pyqir even supports custom control over qubits. If yes, the straightforward way to implement this would be a recursive implementation - for each gate in the gate body, call the ctrl handling method. If a basic gate is encountered, directly apply the control.

Use openqasm gate modifier reference for any clarifications.

Please confirm the following:

• I have searched the existing issues and confirm this is a new feature request.

Feature Description

openqasm supports types like int, float, bool, etc as its classical types. Currently, the declaration of variables or their usage is not supported by the converter. Users should be able to define and user variables and arrays of different types while writing openqasm programs.

Implementation (Optional)

1. Since there can be single variable declarations and arrays, start with single variables first.
2. Handling variable definitions across scopes would be required. Can refer to how openqasm handles this by using a stack of scopes
3. Post this, array declarations should be developed

openqasm reference for classical declarations

Please confirm the following:

• I have searched the existing issues and confirm this is a new feature request.

Feature Description

• Currently, the qasm3 visitor only supports static expression evaluation. Eg. -

# 1 + 3*8 -> Evaluated correctly 
# 1 + a*5 -> Exception thrown

• Since Identifiers are generally present in the openqasm expressions, we look to extend this functionality

Implementation (Optional)

• This requires an evaluation function that replaces the Identifier values according to the "current scope". A modification of the existing implementation of _evaluate_expression in qasm3 visitor could be a good starting point
• A scope definition is required as many identifiers tend to have values only defined in a particular scope. Eg -

gate custom(a) p {
    rx(a / 2) p;
}
qubit q;
custom(0.1) q;

• In the above example, the "scope" must be something like - { "a" : 0.1, ...} and thus replace the value of a correctly while the expression a/2 is being evaluated.
• Note that this is not a single-level evaluation. The scope may change and be passed up to evaluate other expressions. Eg -

gate custom1(b) q{
    rx(pi * b) q;
}
gate custom2(a) p {
    custom1(a / 2) p;
}
qubit q;
custom(0.1) q;

openqasm reference for extending expressions

In OpenQASM 3 the let keyword allows declared quantum bits and registers to be referred to by another name as long as the alias is in scope:

qubit[5] q;
// myreg[0] refers to the qubit q[1]
let myreg = q[1:4];

See https://openqasm.com/language/types.html#aliasing

Add support for converting OpenQASM 3 programs that use aliasing to QIR.

Placeholder test-cases in test_alias.py

Value : $75

Implement OpenQASM 3 $\rightarrow$ QIR conversion module

We would like to bring our codecov from ~93% to as close to 100% as we can. Right now, there are only a total of 20 missed lines.

The coverage report from the latest main branch is also available here: https://app.codecov.io/gh/qBraid/qbraid-qir/

If there are lines that shouldn't be tested (e.g. "pass" statements), you can add those to the "exclude_lines" list in the tool.coverage.report section in pyproject.toml.

To generate the coverage report locally, run

pytest tests --cov=qbraid_qir --cov-report=html --cov-report=term

Then, to view the specific missed lines, you can open the report in a browser window (On OS X) with

open htmlcov/index.html

For example:

Potentially fork https://github.com/Alice-Bob-SW/qiskit-alice-bob-provider for cirq to qir and get API key from alice and bob to test out output programs submitting to their hardware

Feature Description

Integrate the Opsets, Elements and Visitor.py to get the prototype running

Proposed Implementation

No response

Implement minimal working example that converts cirq bell circuit to QIR, e.g. satisfies following test case:

or other alike

Implement opsets gate mappings to be integrated into visitor module.

In qiskit_qir.visitor.BasicQisVisitor.visit_instruction(), they use a long sequence of conditionals to map string gate names to associated functions calls. In our equivalent visit_operation() function, instead of using conditionals, we will define a dictionary in opsets.py that can be imported into visitor.py and retrieve the mapped function calls with $O(1)$ lookup, similar to the pytket-qir module gatesets.py.

Feature Description

• Currently, the code coverage stands at somewhere around 85% for the qasm3-qir module.
• The goal of this issue is to make it > 95%, and ideally 100%

Implementation (Optional)

• Parse missing lines in the coverage report and add tests to cover the same.

Please confirm the following:

• I have searched the existing issues and confirm this is a new feature request.

start writing passing tests for partial and full converted qir program outputs

Examples / resources:

• pytket: https://github.com/CQCL/pytket-qir/blob/6267b4b57302c6bd32c525aab4e33e34110bbc98/pytket/qir/conversion/conversion.py#L101
• pyqir: https://github.com/qir-alliance/pyqir/blob/26885c9dd74d89e11056c980380bc99f337bb03d/examples/mock_to_qir.py#L15

Feature Description

• Openqasm3 supports looping statements as described in their language specification
• Looping support will allow users to pass in more general programs to the qasm3 converter and generate equivalent qir representation

Implementation (Optional)

• Firstly we will need to introduce scope in the converter
• Post this, a loop can be unrolled concerning its scope
• This may either be done as a pre-processing step OR in conjunction with the qir conversion
• A good starting point would be to analyze the ast representation of loops in openqasm

Value : $150

Feature Description

• openqasm 3 also supports switch statements which allow users to condition statement execution based on integral variables.

Implementation (Optional)

• The pyqir._native module does have a definition of the Switch construct but it is not entirely clear how that can be incorporated into the converter. A good starting point would be the pyqir._native definition and the openqasm switch reference

• It would be good to have a handler for the switch, like the _visit_branching_statement. Since switch is also a type of branching instruction, we can either expand this method or create a new handler.

Follow-up to #17

• test cirq to line qubits function and make sure that operations aren't being manipulated in unexpected ways
• implement any necessary gate decompositions against our "supported" gate set.

Add MWE to docs page using sphinx rst / markdown or to README

Weigh pros and cons of converting from cirq.Circuit object or from cirq source code .py file for cirq_to_qir()