Update RB to reduce the size of the generated circuits

[NoureldinYosri]

the cirq RB sequences were often 2-3 times bigger than they should, this is because for historical reasons the cliffords were written as products of X/Z or X/Y gates. In this PR I merge these gates into a single PhasedXZGate which is the same as we do internally.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.68%. Comparing base (b3fe874) to head (722e907).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7411      +/-   ##
==========================================
- Coverage   98.68%   98.68%   -0.01%     
==========================================
  Files        1092     1092              
  Lines       96635    96672      +37     
==========================================
+ Hits        95366    95401      +35     
- Misses       1269     1271       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eliottrosenberg]

Thanks, Nour!! I tested this, and it works!

Could we also change the default value for use_xy_basis in cirq.experiments.parallel_single_qubit_randomized_benchmarking to False, since that is the default value internally? Thanks!

[pavoljuhas]

Please replace _CliffordGateSequence with a simple conversion.

Otherwise LGTM.

[eliottrosenberg]

Before merging, see b/422636519

[pavoljuhas]

LGTM with two small adjustments.

[eliottrosenberg]

Thanks, Nour! This looks a lot better!

I'm noticing that there is more instance-to-instance fluctuation in the error rates with this implementation than with the internal one. See this colab.

[pavoljuhas]

LGTM for the API, thanks Nour!

[NoureldinYosri]

@eliottrosenberg there are two sources of randomness when running RB, the first is intrinsic that comes from running the circuits on a quantum chip, the second is that everytime the method is run a new set of circuits is generated.

the old api which you are using the notebook didn't expose a way to control the circuit generation. the new one does. so if you call parallel_single_qubit_rb(..., rng_or_seed=0) you will match the internal std because currently the default value is None which means a new set of circuits for each run.

[eliottrosenberg]

Approving, but let's follow up to resolve the remaining discrepancies.