-
Notifications
You must be signed in to change notification settings - Fork 118
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
feature: device-specific gate validation for autoqasm programs #695
feature: device-specific gate validation for autoqasm programs #695
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## feature/autoqasm #695 +/- ##
==================================================
Coverage 100.00% 100.00%
==================================================
Files 154 154
Lines 9313 9376 +63
Branches 2014 2035 +21
==================================================
+ Hits 9313 9376 +63
☔ View full report in Codecov by Sentry. |
valid_target_qubits = connectivity_graph[start_qubit] | ||
for qubit in qubits[1:]: | ||
target_qubit = f"{int(qubit)}" | ||
if target_qubit not in valid_target_qubits: |
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.
For my understanding, if the qubit targets are q[0], q[1], q[2], does this only check if q[2] and q[0], q[1] and q[0] are connected? Should it also check whether q[1] and q[2] are connected?
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.
Your understanding is correct. The connectivity graph is directed, so specifically this is checking that the edges q[0]->q[1] and q[0]->q[2] exist.
I actually don't know the desired behavior, because I am not aware of any examples of what the connectivity graph looks like for native 3-qubit gates. For example, imagine a device has a native CCNOT gate - I'm not sure what the connectivity graph should look like for this.
device = self.get_target_device() | ||
if device: | ||
native_gates = self._normalize_gate_names(device.properties.paradigm.nativeGateSet) | ||
allowed_verbatim_gates = self._gates_defined.union(native_gates) |
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.
Does the validation work for defined gates that does not use native gates?
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.
Yes, but now I've added tests which verify this - good catch.
Issue #, if available:
Description of changes:
supportedOperations
of the device properties.Testing done:
Merge Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.General
Tests
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.