Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Use v2 protos in cirq.google.Engine #1779
Use v2 protos in cirq.google.Engine #1779
Changes from 6 commits
e5e769e
1099646
d2578ae
fdef624
20b45c7
cac4fa1
3c1d593
eccc2b7
9f82bfc
34477f9
f9522b3
6e9f88b
33598a6
4619360
793fb8a
16740c2
ef5b450
b8d67d0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I think instead of making this optional and relying on ordering, we should use the
api_v2.find_measurements
function to find measurements in the program before sending to the quantum engine, and store this in theEngineJob
. Then when getting results the list of measurements can be passed in toresults_from_proto
.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.
Shouldn't all the info about the measurements be accessible from the results?
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.
What is your concern with relying on the order in the result? If we want to support re-ordering, could it be a feature/utility rather than a requirement to parse a result?
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.
We want to be sure that the order in which results appear in
TrialResult
match the original measurement operation. Themeasurements
arg onresults_from_proto
is here so we can check the qubit order in the results against the original measure ops, and it's as easy to reorder as to check so that's what it does. If we want to specify that the engine will not reorder (and then assume but not check this), then I'd suggest we remove this argument entirely rather than making it optional.I think it would be good to include the qubit order in
TrialResult
itself to make the results more self-describing. That would alleviate some of my concern because we won't have so many assumptions about parallel ordering between various objects. I knowTrialResult
is getting an overhaul, so maybe we can include the qubit order as part of that change.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.
+1 to including qubit order details in the result.
I'd prefer to remove the
measurements
arg, but that would be a breaking change for existing external dependencies (I found one). My plan was to make this optional to continue support, then, if it was acceptable, remove all references, then clean up by removing the param. LMK if it's fine to just make the breaking change, otherwise I can add comments to that effect.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.
I agree with @dabacon, making this optional for now is fine. We can remove in a future PR.
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.
nit: this follows a very different import strategy than we follow in Cirq. No need to fix now, but generally we don't import classes / method
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.
is there a reason to do this for v1 protos? It would be nice to always just the the run context.
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.
We previously talked about making these changes separately, so I left it as-is. It should be straightforward, so I'll address this after attending to the other comments.
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.
SGTM.
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.
Added. PTAL.