adding new single-qubit gates

[Fe-r-oz]

This PR aims to add the missing single qubit gate w.r.t stim. Added and Tested all the missiing single qubit gates that stim has: https://github.com/quantumlib/Stim/blob/main/doc/gates.md

In this book(https://threeplusone.com/pubs/on_gates.pdf), SQRTX is called V gate, so V gate is used as its name.

julia> sHadamardXY(1)
sHadamardXY on qubit 1
X₁ ⟼ + Y
Z₁ ⟼ - Z

julia> sHadamardYZ(1)
sHadamardYZ on qubit 1
X₁ ⟼ - X
Z₁ ⟼ + Y

julia> sV(1)
sV on qubit 1
X₁ ⟼ + X
Z₁ ⟼ - Y

julia> sInvV(1)
sInvV on qubit 1
X₁ ⟼ + X
Z₁ ⟼ + Y

julia> sSQRTY(1)
sSQRTY on qubit 1
X₁ ⟼ - Z
Z₁ ⟼ + X

julia> sInvSQRTY(1)
sInvSQRTY on qubit 1
X₁ ⟼ + Z
Z₁ ⟼ - X

[Fe-r-oz]

The gates fail this test (hope this is not too bad), The gate pass all the other tests for single-qubit gates.

s = random_destabilizer(1)
Expression: sop * s == sqsop * s == cop * s == csqop * s == tcop * s == stcop * s

[Krastanov]

I would expect there to be a but in the gates if they fail this test.

[Fe-r-oz]

Indeed, some part of implementation is wrong. My bad!

[Fe-r-oz]

Indeed, the implementation was so bad. In particular, The macro qubit kernel descriptions were wrong that's why the failing tests occured in this testset "Convert between small ops".

The build failed because of more occasional (comparison to MC under perturbative expansion purification example testset) error not related to this PR.

The windows latest CI fails because of this error:

Starting tests with 1 threads out of `Sys.CPU_THREADS = 4`...
ERROR: LoadError: InitError: Python: ImportError: DLL load failed while importing _path: The specified procedure could not be found.

[Fe-r-oz]

BTW, A small comment that is not related to this PR:

QuantumClifford.jl/src/QuantumClifford.jl

Line 78 in 263195c

groupify, minimal_generating_set, pauligroup, normalizer, centralizer, contractor, delete_columns,

There is no delete_columns function in the group_tableaux file so when testing locally, there is error due to this. I checked this file, there is no delete_columns function.

[Krastanov]

There is no delete_columns function in the group_tableaux

should be here

QuantumClifford.jl/src/project_trace_reset.jl

Line 887 in 263195c

function delete_columns(𝒮::Stabilizer, subset)

[Fe-r-oz]

Thanks, It seems I don't have this in the test_project_trace_reset!, prolly because I didn't sync the PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.75%. Comparing base (b02add9) to head (4bfd7c3).
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #333      +/-   ##
==========================================
+ Coverage   82.41%   82.75%   +0.34%     
==========================================
  Files          62       62              
  Lines        4162     4308     +146     
==========================================
+ Hits         3430     3565     +135     
- Misses        732      743      +11     

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

[Krastanov]

This looks pretty good. Thank you for spending time on it! I think the only thing left is:

• thinking through whether there is some more idiomatic naming convention for us compared to the DAG suffix. Probably we will just stick to that suffix.
• Having a set of tests that specifically check that gates match the definitions that stim uses. E.g. something like CliffordOperator(gate) == C"Z X" or whatever the appropriate C string is, taken from the markdown file you shared.

[Fe-r-oz]

For us, Inv is the naming convention that has been used. Primarily, it can be seen in the LinearAlgebra.inv method which we use a lot for inv(CliffordOperator(...)). Searching for inv, we see quite a lot of use of this in ~20 files, making it default convention to compared to DAG. Also, sInvPhase and sInvZCrY are existing examples of inv convention. Given that, should we revert back to using Inv?

Please share your thoughts on this. Thank you!

[Fe-r-oz]

Thanks again for the very hepful Task TODO list and feedback! Hopefully, the tasks have been addressed.

[Krastanov]

Thanks, this is very useful!