Conjugation and Hermitian variables

[peterwittek]

I cannot possibly estimate the difficulty of this, but it would be great to define a conjugation or adjoint operation over the variables and monomials. The first interesting case is monomials of complex numbers.

For the noncommuting case, we have important families of Hermitian (self-adjoint) operators like projective measurements, positive operator-valued measures, and Pauli operators, as well as non-Hermitian ones like fermionic and bosonic ladder operators.

In the noncommuting case, the adjoint of the monomial also permutes the order of the variables. This is critically important when we work with moment methods like the NPA hierarchy.

[blegat]

How do we need to treat those conjugates ? Simply as other variables or do we need to use identities like x' * x is 1 for othogonal matrices and x' == x for Hermitian matrices ? It would help me to have a few examples. For instance, is that correct ? : Commuting case (e.g. complex variables)

(x * y' * z)' * (x' * z) = z' * y * x' * x' * z = x'^2 * y * z' * z

Noncommuting case (e.g. matrices)

(x * y' * z)' * (x' * z) = z' * y * x' * x' * z = z' * y * x'^2 * z

[peterwittek]

Your examples are correct. I am not sure how you identify variables internally, but I would rather make Hermicity inherent to the variable, and not defined through identities. So, given x and y Hermitian noncommuting operators (which may or may not be matrices), I would expect to get (x*y)' = y*x.

Extra things like orthogonality or idempotency can be declared as identities, especially if your substitution routines are fast.

[blegat]

I think it is doable. We will probably not create a type for every of the 16 combinations (commutativity, hermitianity, orthogonality and idempotency). I suggest to have 2 types (PolyVar and NCPolyVar) and store hermitianity, orthogonality and idempotency as boolean fields in the type. The reason commutativity is threaten differently is that it does not affect the variable itself rather its multiplication with other variables. At the moment, I do not allow mixing non-commutative and commutative variables. There is the non-commutative world (with NCPolyVar, NCMonomial, ...) and the commutative world (with PolyVar, Monomial, ...) and they cannot be mixed. Do you need to write polynomials that contains both commutative and non-commutative variables ?

[peterwittek]

Sometimes yes, but in a very special way, so I think your separation will work just fine.

The only case when I need some kind of mixing is when we have a real parameter. In such situations, the nc variables are always in some measure (tr(.ρ) for some ρ positive definite operator, quite possibly a quantum state if we normalize the norm by setting tr(ρ)=1), whereas the parameter is not. So imagine you have some A, B nc operators acting on some Hilbert space H, and λ as the real parameter, then you might get a polynomial optimization in this form:

min λ λ∈[0,1],ρ∈H,ρ≥0 s.t. λ tr(Aρ) + (1-λ) tr(Bρ) = some real value

Imagine that you do the SDP relaxation of this problem. Then you would generate moment matrices with A and B, but not with λ. The parameter λ would get a single SDP variable assign to it in the relaxation, but that is it.

Long story short, if there is any form of mixing, the nc operators are always in a measure.

[blegat]

Ok that would work. We need to dinstinguish 3 things in PolyJuMP:

• Decision variables (here λ and ρ (or more precisely, there is one decision variable by moment of ρ that we consider),
• Polynomial Variables (C or NC),
• The coefficients of polynomials / the value of moments.

In PolyJuMP, the coefficients are typically either constant or affine expression of decision variables. A polynomial or measure decision variable has in fact one decision variable for each of its coefficient/moment value.The coefficients which are affine expression of decision variables and the polynomial variables lives in different worlds and it is totally ok to have commutative decision variables with NC polynomial variables.

In MultivariatePolynomials, we never assume anything about the coefficients (That is the big difference with Nemo where they have specific, optimized implementations for specific types of coefficients). So when we have (a * m1) * (b * m2) (where a and b are coefficients and m1, m2 are monomials) we do (a*b) * (m1*m2) (not b*a, a and b could be anything, even matrices). In the product m1*m2, we look inside the monomials and use the PolyVar property (N, NC, ...) to find the resulting monomials but for a*b I let the package having defined the types of a and b do the job without assuming anything (In the case of PolyJuMP, it will be JuMP if the types of a and b are affine exressions of decision variables).

[peterwittek]

This sounds perfect!

[kbarros]

Related question: Is there a recommended way to manually reverse the order of all the factors in each term? The current behavior is:

@ncpolyvar ncpolyvar u v
p = im*u*v
p' # (0 - 1im)uv

How can one write a function with this behavior?

custom_adjoint(p) # (0 - 1im)vu

Thanks.

[blegat]

I don't believe we have anything like that. Probably transpose should reverse the order.

[kbarros]

Probably transpose should reverse the order.

This new behavior (with the name adjoint) would make sense to me. The old behavior could still be achieved with mapcoefficients(adjoint, p).

[blegat]

Even with the name transpose, that would make sense. PR welcome