Skip to content
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

noncliff: Inner Product between two GeneralizedStabilizers #423

Draft
wants to merge 1 commit into
base: nonclif
Choose a base branch
from

Conversation

Fe-r-oz
Copy link
Contributor

@Fe-r-oz Fe-r-oz commented Nov 7, 2024

This PR implements the Inner Product between two Generalized Stabilizers. Inspired from V.Section B of the base paper.

@Fe-r-oz
Copy link
Contributor Author

Fe-r-oz commented Nov 7, 2024

The PR is ready for review. There is an unrelated doctest errors that were fixed in #416 that is why one extra CI-error.

Thank you!

Copy link
Member

@Krastanov Krastanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for starting this! I think there is a bit of a misunderstanding of what the paper is actually doing. The approach implemented here is exponentially slower than the appropriate algorithm from the paper.

The inner product of two [`GeneralizedStabilizer`](@ref) states, `sm₁` and `sm₂`.

```jldoctest
julia> using QuantumOpticsBase; using LinearAlgebra; # hide
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not hide these, otherwise the reader might not know how to run these examples

```
"""
function LinearAlgebra.dot(sm₁::GeneralizedStabilizer, sm₂::GeneralizedStabilizer)
return real(tr(Operator(sm₁)' * Operator(sm₂)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just converts the two generalized stabilizers to density matrices. This is an exponentially expensive operation that does not seem to be implementing what is shown in the paper. This can be a useful correctness test in the test suite, but it is not an appropriate implementation for this library.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Thank you!

I think the right hand side (shown in the proof section) is the faster version that uses in-place operations.

@@ -82,6 +82,7 @@ end
apply!(sm, embed(n, i, pcT))
smcopy = copy(sm)
@test smcopy == sm
@test dot(sm, smcopy) ≈ 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having tests that do not always use the same state on both sides would make this much more trustworthy

@Krastanov Krastanov marked this pull request as draft November 8, 2024 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants