Qiskit / qiskit

Qiskit is an open-source SDK for working with quantum computers at the level of extended quantum circuits, operators, and primitives.
https://www.ibm.com/quantum/qiskit
Apache License 2.0
5.11k stars 2.34k forks source link

Add method to add instructions to a DAGCircuit from an iterator of PackedInstruction #13032

Closed raynelfss closed 3 weeks ago

raynelfss commented 1 month ago

Solves #13003

Summary

Tracked by #13001 and preceeded by #12975 The following commits aim to add a DAGCircuit::extend() to add a chain of DAGOpNodes to the DAGCircuit based on a sequence of PackedInstruction.

Details and comments

These commits add the following two methods:

Known issues:

Blockers

coveralls commented 1 month ago

Pull Request Test Coverage Report for Build 10740673998

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details


Changes Missing Coverage Covered Lines Changed/Added Lines %
crates/circuit/src/dag_circuit.rs 104 111 93.69%
<!-- Total: 104 111 93.69% -->
Files with Coverage Reduction New Missed Lines %
qiskit/transpiler/passes/optimization/split_2q_unitaries.py 1 96.77%
qiskit/transpiler/passes/routing/stochastic_swap.py 1 95.39%
crates/accelerate/src/synthesis/clifford/utils.rs 1 78.06%
crates/circuit/src/dag_node.rs 3 81.2%
crates/qasm2/src/lex.rs 3 93.23%
crates/circuit/src/packed_instruction.rs 11 93.08%
crates/circuit/src/circuit_instruction.rs 12 82.93%
crates/circuit/src/operations.rs 13 88.67%
crates/accelerate/src/results/marginalization.rs 17 90.17%
crates/circuit/src/dag_circuit.rs 44 88.92%
<!-- Total: 106 -->
Totals Coverage Status
Change from base Build 10720509731: 0.008%
Covered Lines: 72737
Relevant Lines: 81585

💛 - Coveralls
qiskit-bot commented 1 month ago

One or more of the following people are relevant to this code:

ElePT commented 3 weeks ago

I believe that the PR doesn't have any open blocker. I will remove the on hold label. Let me know if I missed something.

raynelfss commented 3 weeks ago

I believe that the PR doesn't have any open blocker. I will remove the on hold label. Let me know if I missed something.

I was about to do that :) Thank you

ElePT commented 3 weeks ago

The issue was fixed by #13092, it was unrelated to the changes in this PR :)

kevinhartman commented 3 weeks ago

I can give this a quick look as well if it's helpful (I see it is not in the merge queue yet)

mtreinish commented 3 weeks ago

IMO, this new method is sufficiently complex and should be unit tested. I'm not sure if we've decided on an approach to exercise the Rust-only API of our pyclasss. Perhaps @mtreinish has opinions / suggestions?

In general having rust unit tests is possible and we have them already in place where it is possible/makes sense for PRs like this with new rust specific functionality. See: https://github.com/Qiskit/qiskit/commit/86c63eb3d719a129dbcb92c56e9a67954030b803 for a recent example (which is already setup to run in CI: https://dev.azure.com/qiskit-ci/qiskit/_build/results?buildId=60452&view=logs&j=b9878877-bc64-52fc-fc03-577dd0aa7cb4&t=2cc4852e-f347-585e-188c-b93a0bf20b0f&l=363 ). But what we will struggle with here is that this new method takes a py token and we don't have a mechanism to interact with python via rust unit tests.

I would agree we should have this exercised somehow in an ideal world. But I think we probably are ok to let this slide if we can't come up with a solution for unit testing with a python dependency. Given that there are several PRs actively based on top of this and those are exercising the code and tested via Python AFAICT.