-
Notifications
You must be signed in to change notification settings - Fork 12
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 factor of 6 #161
Remove factor of 6 #161
Conversation
🚀 Code Coverage
|
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.
Looks good! My only suggestion is that in your PR comments that instead of linking to the Jira ticket (which people outside of Zapata can't see) that you paste the content from the Jira ticket into your PR description. This would help someone follow why this change was made.
@@ -467,7 +467,7 @@ def estimate_resources_from_compiled_implementation( | |||
|
|||
# get time to get a single shot | |||
time_per_circuit_in_seconds = ( | |||
6 * num_cycles * hw_model.surface_code_cycle_time_in_seconds | |||
num_cycles * hw_model.surface_code_cycle_time_in_seconds |
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.
Just a comment: I was surprised to see that the unit tests are still passing after making this change. But, I now see that it is because our tests don't depend on the absolute value of time_per_circuit_in_seconds, but only on how this value is expected to change with respect to other parameters (e.g. physical error rate). I think this is good because it shows that these tests are checking something that we expect to be the case rather than checking output values against values generated from the tests themselves, which are weaker and subject to breaking even when the code is updated properly.
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.
Looks good!
Description
Summary:
The issue involves removing the factor of 6 from BenchQ to correct inconsistencies in the runtime calculation.
Context:
This factor of six is because the syndrome extraction circuits have depth 6 when assuming direct physical ability to initialise and readout qubits in the X-basis. There is a discrepancy in the terminology used, which stems from the historical use of gate_time instead of surface_code_cycle_time. The factor of six needs to be removed to align the equations with the updated terminology.
Implemented solution:
Removed factor of 6 from time_per_circuit_in_seconds in graph_estimator.py in line 469