# ComplexOptInterface

**This package is this in early development, feedback is welcome!**

Build Status |
Social |
---|---|

An extension of MathOptInterface to complex sets. There are two types of complex sets:

- Some sets have complex entries, i.e.
`MOI.EqualTo{Complex{Float64}}`

, - Some sets have real entries even if they model a complex mathematical set, i.e.
`HermitianPositiveSemidefiniteConeTriangle`

where the imaginary part of the off-diagonal entries are stored in separate output indices. For instance,`[x y+zim; y-zim w]`

is vectorized as`[x, y, w, z]`

.

Sets with complex entries **should not** be used with `Single`

or `VectorOfVariables`

constraints
as the variables in MathOptInterface are assumed to be real.
Indeed, for instance doing

`x, cx = MOI.add_constrained_variable(model, MOI.EqualTo(1 + 2im))`

fallbacks to

```
x = MOI.add_variable(model)
cx = MOI.add_constraint(model, MOI.SingleVariable(x), MOI.EqualTo(1 + 2im))
```

In the first line, the solvers create a real variable.
Moreover, in the bridge from `MOI.ScalarAffineFunction{Complex{T}}`

-in-`EqualTo{Complex{T}}`

to `ScalarAffineFunction{T}`

-in-`EqualTo{T}`

, we assume that the variables are real
to split the equality in real and imaginary part.
So in conclusion, complex variables may violate assumptions in MOI so use it at your own risks.
Note that even if you add a `MOI.ScalarAffineFunction{Complex{T}}`

-in-`EqualTo{Complex{T}}`

constraint,
it may be bridged by a slack bridge into a variable constrained in `EqualTo{Complex{T}}`

.
Luckily, this bridge might not be selected but remain causious with sets with complex entries.