Codecov Report

All modified and coverable lines are covered by tests ✅

... and 1 file with indirect coverage changes

@akirakyle the implementation of randchannel in this PR breaks the Gaussian CP map condition N + iΩ ≥ iTΩTᵀ:

julia> nmodes = rand(1:20);

julia> rc = randchannel(nmodes);

julia> Omega = symplecticform(nmodes);

julia> @test all(i -> ((i >= 0) || isapprox(i, 0.0, atol = 1e-5)), real(eigvals(rc.noise .+ im*Omega .- im*rc.transform*Omega*rc.transform')))
Test Failed at REPL[15]:1
  Expression: all((i->begin
            #= REPL[15]:1 =#
            i >= 0 || isapprox(i, 0.0, atol = 1.0e-5)
        end), real(eigvals((rc.noise .+ im * Omega) .- im * rc.transform * Omega * (rc.transform)')))

Any idea why this is? I checked my work with Serafini's discussion on pgs. 98 and 99 and it looks fine to me.

Hmmm, staring at the code of randchannel I don't see anything obvious. The checks for randsymplectic are passing?

I think one observation which would simplify the code is that it is actually not necessary to have an environment covariance matrix other than identity if the goal is to generate random channels since a random unitary on 2n modes corresponds to a random channel on n modes after tracing out the other n modes assuming they are in vacuum. Physically the intuition behind this is that noise on the n mode subsystem will arise due to two-mode squeezing with the environment as tracing out one mode of such a state reveals a thermal state.

Perhaps try simplifying the code with this observation first then see if the checks are failing.

Found the problem. The issue was that I derived transform and noise matrices for randchannel in the canonical basis. However, my tests were with symplectic forms in the block diagonal basis, which were generated with symplecticform. That's my bad. Given that most papers on Gaussian quantum info use the canonical basis, I will make a breaking change in this PR that changes the matrix generated by symplecticform to be that in the canonical basis, e.g.,

julia> symplecticform(2)
4×4 Matrix{Float64}:
  0.0  1.0   0.0  0.0
 -1.0  0.0   0.0  0.0
  0.0  0.0   0.0  1.0
  0.0  0.0  -1.0  0.0

All the tests pass now. I should make a point about symplectic basis in the documentation soon.

Perhaps try simplifying the code with this observation first then see if the checks are failing.

This note was still very helpful and was used to simplify the internals behind randchannel. Thanks!

Ah yes the explicit representation of the symplectic form is perhaps the most important thing as it dictates the representation of all other objects in the Gaussian formalism! While the representation you're calling "canonical" is the one used by Weedbrook and Serafini and seemingly most common among QI theorists these days, one often encounters the "sigma z" representation given by Serafini Eq. 3.7 in more engineering focused contexts as that representation is closely related to the classical scattering matrix response a linear time-translation-invariant system. For example see this paper https://arxiv.org/abs/2410.09976. I'm actually quite interested in also having ways model the kind of frequency selective gaussian operations that that paper discusses and such systems can be also be described by the symplectic group, just either with different representation or reinterpretation of the physical nature of the operators.

I think while developing the functionality of this library it's good to fix the symplectic representation to avoid confusion such as the one you encountered, but long term it would be really helpful to support all the different representations with functions to convert between them!

I think while developing the functionality of this library it's good to fix the symplectic representation to avoid confusion such as the one you encountered, but long term it would be really helpful to support all the different representations with functions to convert between them!

Yeah, I was thinking about that after I merged this PR. I definitely agree that it would be helpful to support different symplectic representations. One way to do it would be to define new symplectic representation types that carry information about the number of modes in the bosonic system, e.g.,

struct CanonicalForm{N<:Int} <: AbstractSymplecticRepr
    nmodes::N
end

Then have Gaussian objects such as GaussianState, GaussianUnitary, etc wrap around these types rather than an integer specifying the number of modes, e.g.,

struct GaussianState{M,V,R<:AbstractSymplecticRepr} <: StateVector{M,V}
    mean::M
    covar::V
    repr::R
end

This kind of opens a whole can of worms, but I'll probably implement some manifestation of this sooner rather than later since this package is still in its alpha state and breaking releases aren't as horrible. It'd be a nice Thanksgiving project :)

Yeah something like that seems like a good, julian approach to me!