-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Remove qubit pair ordering requirement in SerializableDevice #5642
Remove qubit pair ordering requirement in SerializableDevice #5642
Conversation
@@ -121,7 +121,7 @@ def test_metadata_correct(): | |||
pairs = [ | |||
(qubits[0], qubits[1]), | |||
(qubits[0], qubits[3]), | |||
(qubits[1], qubits[4]), | |||
(qubits[4], qubits[1]), |
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.
Sorry, can you describe what was happening here and what should be happening here? Was this a latent bug? What this pair just not added to the device topology because the constructor expects ordered pairs but got unordered pairs? What defense do you have against passing unordered pairs to the GridMetadata constructor?
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.
Looked into this again, and turns out the previous code was fine. For each SYMMETRIC
target in the DeviceSpecification
proto, two tuples are created in the gate definition, one for each direction of the pair:
target_set.add(qid_tuple[::-1]) |
so the pair[0] < pair[1]
deduplicates the pair, and no qubit pairs should be omitted.
I'll go ahead and close this PR (including the test case change), since SerializableDevice
will be removed soon. But let me know if you feel otherwise.
What defense do you have against passing unordered pairs to the GridMetadata constructor?
In the current GridDeviceMetadata
implementation, qubit pairs passed into the constructor are considered to be unordered
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.
That works as long as you're coming via that proto code path, but if you're just using the bare __init__
method, could you get yourself into hot water?
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.
Yeah that is true. I am OK either way since the preferred method to construct SerializableDevice
is from_proto()
(as mentioned in the __init__
docstring).
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.
that seems dangerous to me.
When is this class getting removed?
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.
bump
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 class is now gone in Cirq 1.0. PR: #5743
I did not dig into the detail, but the updated test passes with the unchanged serializable_device.py module. |
Closing (rationale in #5642 (comment)) |
This call site was missed after #5169 was fixed.
If
gate_definitions
contain a pair of the same qubit, GridDeviceMetadata will throw a ValueError.@mpharrigan