-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add method to add instructions to a DAGCircuit from an iterator of PackedInstruction #13032
Conversation
Pull Request Test Coverage Report for Build 10740673998Warning: 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
💛 - Coveralls |
One or more of the following people are relevant to this code:
|
5729293
to
74d8b03
Compare
7056ab4
to
0288597
Compare
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. |
- Introduce a method that adds a chain of `PackedInstruction` continuously avoiding the re-linking of each bit's output-node until the very end of the iterator. - TODO: Add handling of vars - Add header for a `from_iter` function that will create a `DAGCircuit` based on a chain of `PackedInstruction`.
- Fix incorrect re-insertion of last_node.
- Remove `from_iter`
- Use `entry` api to either modify or insert a value if missing.
- A bug that adds duplicate edges to vars has been temporarily fixed. However, the root of this problem hasn't been found yet. A proper fix is pending. For now skip those instances.
- A set collecting all the new nodes to connect with a new node was preventing additional wires to connect to subsequent nodes.
0288597
to
3cb950e
Compare
I was about to do that :) Thank you |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @raynelfss! This PR is quite useful for transpiler passes that build new instructions (like unitary synthesis). I have been using these changes in my PR and everything has worked as expected so far, so you can have that as a "unit test" data point. I might be overseeing something but I would approve this PR after addressing a few minor (and quite superficial) comments.
- Caught by @ElePT Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think I have found an issue when trying to add instructions that have no clbits. When I initialize a packed instruction with clbits: target_dag.cargs_interner.get_default()
, I then get a the caller is responsible for only using interner keys from the correct interner
error. I will try to come up with a minimal example that reproduces the problem.
I want to make sure there are no issues for the case with empty clbits
The issue was fixed by #13092, it was unrelated to the changes in this PR :) |
I can give this a quick look as well if it's helpful (I see it is not in the merge queue yet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good, thanks for adding this @raynelfss!
The one larger point I think we should start to be weary of is introducing new methods that aren't covered by any of our existing testing. We've operated in a bit of a free-for-all the last few months while porting things to Rust, under the assumption that our existing Python test code would provide sufficient coverage.
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 pyclass
s. 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: 86c63eb 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 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. |
- Use Entry API to modify last nodes in the var. - Build new_nodes with an allocated vec. - Add comment explaining the removal of the edge between the output node and its predecessor.
- Use `or_insert_with` instead of `or_insert` to perform actions before inserting a value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the changes!
Solves #13003
Summary
Tracked by #13001 and preceeded by #12975
The following commits aim to add a
DAGCircuit::extend()
to add a chain ofDAGOpNodes
to the DAGCircuit based on a sequence ofPackedInstruction
.Details and comments
These commits add the following two methods:
DAGCircuit::extend()
to add a sequence ofPackedInstruction
continously avoiding having to re-add each bit/var's output node each time an instruction is added. The addition of the output node is only performed once all instructions have been added correctly to the DAGCircuit.Known issues:
PyObject
which are not hashable.One possible solution would be to use a.PyDict
however the structures that are being stored within this mapping are rust-native (NodeIndex
,Wire
)Another solution would be to somehow internalize these structures, which I'm still thinking on how to do.Blockers
DAGCircuit
in Rust. #12975 (will rebase once merged)DAGCircuit
to Rust #12550