noncliff: define `_proj` subroutine for `projectrand!` #355

Fe-r-oz · 2024-09-08T10:22:43Z

PR implements project! for noncliff. Basic tests are added as well.

The code is properly formatted and commented.
Substantial new functionality is documented within the docs.
All new functionality is tested.
All of the automated tests on github pass.

Fe-r-oz · 2024-09-27T16:54:31Z

I think the PR is ready for review. I hope it's not awkward. Thank you!

Krastanov

Thanks for starting this, it is incredibly helpful to have someone tackle it.

I left a few comments in, but I think there is a bigger thing that is currently unclear to me: in _proj₊ you access only the base tableau out of which all terms in the weighted sum are generated, but you do not access any of those terms themselves, nor are their relative weights taken into account. And it seems that you are returning a pure state, not a GeneralizedStabilizer. But one single measurement is not enough to turn a mixed state into a pure state, so there must be an issue with the current code.

src/nonclifford.jl

test/test_nonclifford_quantumoptics.jl

Krastanov · 2024-09-27T17:34:44Z

test/test_nonclifford_quantumoptics.jl

@@ -50,3 +50,18 @@ qo_tgate.data[2,2] = exp(im*pi/4)
        end
    end
 end
+
+@testset "project!" begin


These tests do not really check the projection operation results. They just run some projection operation and make sure that errors are not raised, but do not do verification.

We also should try something that is not exclusively single-qubit.

Something like this maybe:

for n in 1:4 for repetition in 1:5 s = random_stabilizer(n) p = random_pauli(n) gs = GeneralizedStabilizer(s) for i in 1:rand(1:3) apply!(gs, appropriately_padded_pcT) # this might need an `embed` or `tensor` end qo_state = Operator(gs) projectrand!(gs) qo_state_after_proj = Operator(gs) # finally, compute the projected result with QuantumOptics and compare qo_pauli = Operator(p) qo_proj1 = (Identity - qo_pauli)/2 qo_proj2 = (Identity - qo_pauli)/2 result1 = qo_proj1*qo_state*qo_proj1' result2 = qo_proj2*qo_state*qo_proj2' @test qo_state_after_proj ≈ result2 || qo_state_after_proj ≈ result1

Thanks a lot for this! That is really appreciated.

Fe-r-oz · 2024-10-01T04:58:44Z

Thanks for your pertinent observation. Indeed, something was wrong as I was only considering the tableau, not the catering X. What I overlooked was that in the base paper, Ted tells us to update the GeneralizedStabilizer state τ with the reduced χ-matrix namely χ' after performing the measurement (expect). That I did not...

This is why Ted says that 'trace Tr [τ′] = Tr [χ′] is the probability of measuring 0' when talking about the case of measuring 0. My bad...

Now, we have deterministic project! and random projectrand!.

Fe-r-oz · 2024-10-01T17:35:48Z

The PR is ready for review, Thank you!

Krastanov

Thanks for continuing with this. It seems there are a few mistakes in the tests. Could you look into them?

Krastanov · 2024-10-25T02:05:51Z

src/nonclifford.jl

 function _proj₊(sm::GeneralizedStabilizer, p::PauliOperator)
+    newstab, res = projectrand!(sm.stab, p)
+    χ′ = expect(p, sm)
+    n = nqubits(newstab)
+    newsm = GeneralizedStabilizer(newstab, DefaultDict(0.0im, (falses(n),falses(n))=>χ′))
+    return newsm, res
 end

+function _proj₋(sm::GeneralizedStabilizer, p::PauliOperator)
+    newstab, res = projectrand!(sm.stab, -p)
+    χ′ = expect(p, sm)
+    n = nqubits(newstab)
+    newsm = GeneralizedStabilizer(newstab, DefaultDict(0.0im, (falses(n),falses(n))=>χ′))
+    return newsm, res
+end


there is a lot of code repetition here. It seems it would be simpler if on line 224 we just change the sign of p -- then we do not need separate proj+ and proj- functions.

Addressed with the latest commit a6c5fed

Krastanov · 2024-10-25T02:07:55Z

src/nonclifford.jl

+    newstab, res = projectrand!(sm.stab, -p)
+    χ′ = expect(p, sm)


It seems you are modifying an internal detail of sm before you are calling expect on it. Is sm still a valid object after this operation?

Krastanov · 2024-10-25T02:09:25Z

src/nonclifford.jl

+    newstab, res = projectrand!(sm.stab, -p)
+    χ′ = expect(p, sm)
+    n = nqubits(newstab)
+    newsm = GeneralizedStabilizer(newstab, DefaultDict(0.0im, (falses(n),falses(n))=>χ′))


For this to be a valid object we need χ′==1, right? Is that always the case (e.g. you can use this to check for bugs)? If this is always the case (i.e. no bugs detected), then we can presumably just skip the computation of χ′.

χ′ is the updated density matrix which is not necessarily be 1 as this is observed when we apply a non-clifford op to sm, and them find expectation value of a given pauli operator using expect as done in the doctest. In that particular case, χ′ = 0.7071067811865475 as seen in doctest whose probability is ~0.85.

test/test_nonclifford_quantumoptics.jl

Fe-r-oz · 2024-10-25T14:03:38Z

Thank you for your feedback.

I've removed projectrand! from this PR, as I don’t have clarity on whether χ' is needed in projectrand!, based on your comment here: discussion link.

This PR focuses solely on implementing project!, which corresponds to Algorithm 2 in Ted's paper. Regarding project!, Ted states that we should update the GeneralizedStabilizer state τ with the reduced χ-matrix, specifically χ', after performing the measurement (expectation). That is why we take the trace (i.e., $\text{Tr} [\tau'] = \text{Tr} [χ']$) to calculate the probability of obtaining 0 or non-zero. I hope this sounds reasonable.

I’ll address projectrand! in a separate PR after giving it more thought in light of your feedback.

I attempted to use the suggested test (shown below) from this comment: discussion link, but I encountered an error when testing with Stabilizer/MixedDestabilizer. Consequently, I added a similar test in the test section that passes for both GeneralizedStabilizer and Stabilizer/MixedDestabilizer.

While the test may be basic, I would appreciate your feedback on its conceptual correctness. I hope it doesn't fall into the trap of being tautologically true. The tests pass for gs when changed to checks = [(random_stabilizer(1), random_pauli(1))] as well. It appears that using a repetition loop outside or employing more than one qubit results in errors, even when utilizing the Stabilizer instead of GeneralizedStabilizer

Thank you again for your guidance, and I look forward to your thoughts.

# gives error for Stabilizer/MixedDestabilizer
julia> @testset "project! for Stabilizer/MixedStabilizer" begin
           for n in 1:4
               for repetition in 1:5
                   s = random_stabilizer(n) # or md = MixedDestabilizer(random_stabilizer(n))
                   p = random_pauli(n)
                   apply!(s, p)
                   qo_state = Operator(s)
                   project!(s, p)[1]
                   qo_state_after_proj = Operator(s)
                   qo_pauli = Operator(p)
                   qo_proj1 = (identityoperator(qo_pauli) - qo_pauli)/2
                   qo_proj2 = (identityoperator(qo_pauli) + qo_pauli)/2
                   result1  = qo_proj1*qo_state*qo_proj1'
                   result2  = qo_proj2*qo_state*qo_proj2'
                   @test qo_state_after_proj ≈ result2 || qo_state_after_proj ≈ result1
               end
           end
       end

Krastanov

Thanks for working on this. There are some issues on semantics in terms of what project! and projectrand! are supposed to mean and the tests seem to be missing a lot of cases.

Krastanov · 2024-11-02T13:19:24Z

test/test_nonclifford_quantumoptics.jl

@@ -50,3 +50,20 @@ qo_tgate.data[2,2] = exp(im*pi/4)
        end
    end
 end
+
+@testset "project!" begin
+    checks = [(S"X",P"X"),(S"Y",P"Y"),(S"Z",P"Z"),(S"-X",P"-X"),(S"-Y",P"-Y"),(S"-Z",P"-Z")]


This tests only very specific simple states. Right now I do not believe this is actually correct for more complicated states like:

multi-qubit states

non-stabilizer states

Using random_stabilizer and applying a few non-Clifford gates at random qubits would make this much more believable. It can be in a separate testset to help readability, so no need to necessarily modify what is already here.

and multiqubit pauli operators

Krastanov · 2024-11-02T13:20:46Z

test/test_nonclifford_quantumoptics.jl

+        qo_proj2 = (identityoperator(qo_pauli) + qo_pauli)/2
+        result1 = qo_proj1*qo_state*qo_proj1'
+        result2 = qo_proj2*qo_state*qo_proj2'
+        @test qo_state_after_proj ≈ result2 || qo_state_after_proj ≈ result1


it would also be nice to check that one of result1 or result2 is the zero matrix given that you are working stabilizer states only here

This has been now implemented with projectrand!

The condition where result1 or result2 is zero is probabilistic, particularly when the test is repeated multiple times. This holds true even for Stabilizer and MixedDestabilizer projections, particularly when using multi-qubit random_stabilizer states and multi-qubit random_pauli operators

Krastanov · 2024-11-02T13:22:11Z

src/nonclifford.jl

+Base.copy(sm::GeneralizedStabilizer) = GeneralizedStabilizer(copy(sm.stab),copy(sm.destabweights))
+
+Base.:(==)(sm₁::GeneralizedStabilizer, sm₂::GeneralizedStabilizer) = sm₁.stab==sm₂.stab && sm₁.destabweights==sm₂.destabweights
+


these would be nice to add (maybe closer to where struct GeneralizedStabilizer is defined), so if this PR gets protracted feel free to add them in a separate PR (which probably will get merged faster). Just make sure to add some consistency tests for them.

Thanks for the suggestion, implemented in #419

Krastanov · 2024-11-02T13:26:58Z

src/nonclifford.jl

+ 0.707107+0.0im | + _ | + _
+```
+
+"""
 function project!(sm::GeneralizedStabilizer, p::PauliOperator)


I do not think I understand what this project! function is meant to mean.

It is not a simulation of a (potentially nondeterministic) projective measurement (that would be projectrand! and it would involve some randomness in the output)

It is not what project! usually means in this library (a deterministic operation that tells you whether your measurement operator commutes with your stabilizers, and depending on whether it commutes it performs a variety of extra steps to tell you what the state would be after projection). I actually do not believe one can even define project! consistenly for GeneralizedStabilizer. After all, what would be the meaning of anticom and res in that case.

In short: I think this needs projectrand! and not project!. I think earlier in a related PR there was already a discussion of that semantic issue. Maybe we should even define project!(::GeneralizedStabilizer, ::Pauli) = error(...) with an explanation why projectrand! needs to be used.

Thank you! I’ve consolidated _proj+ and proj- into a single _proj, and added a detailed explanation in #416 with definition of project!(::GeneralizedStabilizer, ::Pauli) = error(...).

…ates

…starting point

…ates

…projected states

Fe-r-oz · 2024-11-08T22:31:01Z

Thank you for your valuable feedback!

This PR builds upon the scaffolding introduced in #420, addresses #418, and includes a test for GeneralizedStabilizer from #424. It demonstrates multi-qubit projection using random_stabilizer states and the random_pauli operator for GeneralizedStabilizer, which also holds for Stabilizer and MixedDestabilizer. The remaining task is to add tests for non-stabilizer case, which pass probabilistically but require additional work. Overall, this PR demonstrates that GeneralizedStabilizer encompasses all the capabilities outlined in the Gottesman-Knill theorem.

Edit:

The MixedDestabilizercase from #424 has been added as a reference to demonstrate consistent multi-qubit projection results for stabilizer simulation when compared with GeneralizedStabilizer

graph TD

subgraph NittyGritty [ ]
        direction TB
        D--> D1[define_proj]
    end

subgraph Tests [ ]
    direction TB
     E[Consistency Tests] --> E1[random_stabilizer, *done* <br>random_pauli, *done* <br> random_clifford, *done* <br> non-stabilizer **remaining**]
 end

    subgraph ScaffoldingBranch [ ]
        direction TB
        B[Scaffolding] --> B1[completed]
    end
    subgraph ErrorBranch [Unrelated Errors, <br> Issue #418]
        direction TB
        C[Unrelated Errors, <br> Issue #418] --> C1[Resolve projection inconsistencies for multi-qubit Stabilizer/MixedDestabilizer]
    end
    A[projectrand!] --> C
    A[projectrand!] --> B
  A[projectrand!] --> E
    A --> D[Nitty Gritty]

…dStabilizer states for stabilizer simulation

Fe-r-oz · 2024-11-09T10:32:40Z

This PR is ready for review, Thank you!

implement project! for genstab

ed0c0ba

Fe-r-oz force-pushed the project branch from fb457bb to ed0c0ba Compare September 8, 2024 10:42

Fe-r-oz added 4 commits September 21, 2024 16:10

Merge branch 'nonclif' into project

3642472

improve documentation and code quality

22df2fb

Merge branch 'nonclif' into project

434ba32

fix misc errors

dd48b53

Fe-r-oz force-pushed the project branch from ad7e3c7 to dd48b53 Compare September 27, 2024 14:31

Fe-r-oz marked this pull request as ready for review September 27, 2024 14:56

Krastanov requested changes Sep 27, 2024

View reviewed changes

Krastanov marked this pull request as draft September 27, 2024 17:39

Fe-r-oz force-pushed the project branch from bb325d2 to de175c6 Compare October 1, 2024 04:55

add codereview suggestions: project! and projectrand!

8047c52

Fe-r-oz force-pushed the project branch 3 times, most recently from 18a3b7b to b367530 Compare October 1, 2024 16:21

improve code quality and add tests for project! and projectrand!

9bb0e1a

Fe-r-oz force-pushed the project branch from b367530 to 9bb0e1a Compare October 1, 2024 16:29

Fe-r-oz marked this pull request as ready for review October 1, 2024 17:30

Fe-r-oz requested a review from Krastanov October 1, 2024 17:35

Fe-r-oz mentioned this pull request Oct 9, 2024

Completing the non-Clifford capabilities [$800] #309

Open

Krastanov requested changes Oct 25, 2024

View reviewed changes

Krastanov marked this pull request as draft October 25, 2024 02:17

Fe-r-oz force-pushed the project branch from 0e2d219 to 45ef073 Compare October 25, 2024 07:40

remove projectrand!

b1901cb

Fe-r-oz force-pushed the project branch from 45ef073 to b1901cb Compare October 25, 2024 12:21

Merge branch 'nonclif' into project

3fc78cc

Fe-r-oz marked this pull request as ready for review October 25, 2024 14:07

improve code quality of project!

d4a5800

Fe-r-oz requested a review from Krastanov October 28, 2024 17:35

Krastanov requested changes Nov 2, 2024

View reviewed changes

Krastanov marked this pull request as draft November 2, 2024 13:28

Fe-r-oz mentioned this pull request Nov 3, 2024

noncliff: enhanced error message for inapplicable Project! of GeneralizedStabilizer #416

Merged

5 tasks

add test to show result1 == zero or result2 == zero for stabilizer st…

ba879f8

…ates

Fe-r-oz changed the title ~~noncliff: implement project!~~ noncliff: implement projectrand! Nov 3, 2024

implement projectrand! method and add tests for single-qubit base as …

a6c5fed

…starting point

This was referenced Nov 3, 2024

noncliff: add copy, == for GeneralizedStabilizer, UnitaryPauliChannel #419

Merged

noncliff: scaffolding for projectrand! for GeneralizedStabilizer #420

Merged

Merge branch 'nonclif' into project

306423b

Fe-r-oz changed the title ~~noncliff: implement projectrand!~~ noncliff: define _proj subroutine for projectrand! Nov 8, 2024

Fe-r-oz force-pushed the project branch 3 times, most recently from 810fc91 to 9e2ef48 Compare November 8, 2024 13:05

Multi-qubit projections using GeneralizedStabilizer for stabilizer st…

6966d11

…ates

Fe-r-oz force-pushed the project branch from 9e2ef48 to 6966d11 Compare November 8, 2024 13:07

Fe-r-oz mentioned this pull request Nov 8, 2024

Inconsistencies in projection tests for Stabilizer/MixedDestabilizer states using multi-qubit random_stabilizers and multi random_paulis #418

Closed

use random_clifford in the multi-qubit projection test and normalize …

1afdf8a

…projected states

Fe-r-oz force-pushed the project branch from 8dce951 to 1afdf8a Compare November 8, 2024 21:43

Fe-r-oz marked this pull request as ready for review November 8, 2024 22:28

Fe-r-oz added 3 commits November 9, 2024 11:56

show consistent comparison by using MixedDestabilizer, and Generalize…

7ed7033

…dStabilizer states for stabilizer simulation

Merge branch 'nonclif' into project

e6e21fd

improve code quality and formatting

6fe89f7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

noncliff: define `_proj` subroutine for `projectrand!` #355

noncliff: define `_proj` subroutine for `projectrand!` #355

Fe-r-oz commented Sep 8, 2024

Fe-r-oz commented Sep 27, 2024

Krastanov left a comment

Krastanov Sep 27, 2024

Fe-r-oz Sep 27, 2024

Fe-r-oz commented Oct 1, 2024

Fe-r-oz commented Oct 1, 2024

Krastanov left a comment

Krastanov Oct 25, 2024

Fe-r-oz Nov 3, 2024

Krastanov Oct 25, 2024

Krastanov Oct 25, 2024

Fe-r-oz Nov 3, 2024

Fe-r-oz commented Oct 25, 2024 •

edited

Loading

Krastanov left a comment

Krastanov Nov 2, 2024

Krastanov Nov 2, 2024

Krastanov Nov 2, 2024

Fe-r-oz Nov 3, 2024

Fe-r-oz Nov 8, 2024 •

edited

Loading

Krastanov Nov 2, 2024

Fe-r-oz Nov 3, 2024

Krastanov Nov 2, 2024

Fe-r-oz Nov 3, 2024

Fe-r-oz commented Nov 8, 2024 •

edited

Loading

Fe-r-oz commented Nov 9, 2024

		newstab, res = projectrand!(sm.stab, -p)
		χ′ = expect(p, sm)

		Base.copy(sm::GeneralizedStabilizer) = GeneralizedStabilizer(copy(sm.stab),copy(sm.destabweights))

		Base.:(==)(sm₁::GeneralizedStabilizer, sm₂::GeneralizedStabilizer) = sm₁.stab==sm₂.stab && sm₁.destabweights==sm₂.destabweights

noncliff: define _proj subroutine for projectrand! #355

Are you sure you want to change the base?

noncliff: define _proj subroutine for projectrand! #355

Conversation

Fe-r-oz commented Sep 8, 2024

Fe-r-oz commented Sep 27, 2024

Krastanov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fe-r-oz commented Oct 1, 2024

Fe-r-oz commented Oct 1, 2024

Krastanov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fe-r-oz commented Oct 25, 2024 • edited Loading

Krastanov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fe-r-oz Nov 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Fe-r-oz commented Nov 8, 2024 • edited Loading

Fe-r-oz commented Nov 9, 2024

noncliff: define `_proj` subroutine for `projectrand!` #355

noncliff: define `_proj` subroutine for `projectrand!` #355

Fe-r-oz commented Oct 25, 2024 •

edited

Loading

Fe-r-oz Nov 8, 2024 •

edited

Loading

Fe-r-oz commented Nov 8, 2024 •

edited

Loading