Hi there,
Do you think sqrt
of special cases of QuadExpr
is useful or dangerous?
Currrently the user gets a warning when using the unsupported nonlinear operator sqrt
and has to do manual reformulation (where possible).
Pro: possible reformulation / simplification can be done automatically
Con: potential modeling issues are hidden from the user, confusion when building models with parameters not yielding special case QuadExpr
(sometimes works vs. sometimes errors)
The generic quadratic expression is
for which we cannot take the squareroot symbolically.
However, for constant and single quadratic variable, it’s possible:
The solution of Q_{i,i} = 0 has a double solution in \mathbb{R}, so I consider this reformulation to be save (i.e. doesnt change feasible set).
Context:
I had to play around with this a little bit when using Second Order Cones and Vector norms / sums of squares in the context of chance constraint optimization.
Using PolyChaos.jl
, I build sometihng like
# mop is struct needed for numerical evaluation
# Y is PCE coefficient vector with entries AffExpr
t = mean(Y, mop)
x = std(Y, mop) # = sqrt.(var(Y, mop))
@constraint(m, [t ; x] in SecondOrderCone())
var
generates the QuadExpr
. However, they are always in a single variable without affine parts.
I implemented a reformulation as an alternative while debugging a model. My problem is solved with first calculating \sqrt{a_{i,i}} and setting x = sq_a .* Y
.