Sum of Squares Matrix

[blegat]

With @polyconstraint, the syntax is

@polyconstraint m A >= 0

where A is a matrix.
Now,

@constraint m A >= 0

creates the elementwise SOS constraints and it would be inconsistent to do something else.
What would be the new syntax ?

We could have

@constraint m A in SOSM

without needing to change anything in JuMP.

One other option would be to both have

@constraint m A in SDP
@SDconstraint m A

and change the SDconstraint macro so that it calls constructconstraint!(expr, SDP) instead of calling SDConstraint directly.

@joehuchette what do you think ?

[joehuchette]

I think the set inclusion version (first) is clearest. Why SOSM instead of SOS?

[joehuchette]

Actually, @SDconstraint(m, A) makes sense as well. I would be OK with either (both?) I think.

[blegat]

Yes both is also possible, I was hoping you would say that :)
SOSM is for SOS Matrices. SOS only would be ambiguous since it could mean elementwise SOS.

[joehuchette]

Hmm OK. I wouldn't necessarily think of the element-wise version, but it is somewhat ambiguous. Maybe the @SDconstraint version is preferable, then.

[chriscoey]

the conic interface will be redone soon (@mlubin), and the cone name :SDP will change. SDP is my pet peeve - it should be PSD.

it would also be nice if we can avoid having a separate @SDconstraint macro for PSD constraints. though yes, I recognize more is going on there, like checking symmetry etc

[chriscoey]

maybe we should figure out in general what these set objects will look like in the new mathprogbase "set inclusion" optimization interface - which needs more thought - and then decide what syntax to use here in PolyJuMP.

depending on how we want to design "set" objects in the near future, maybe the "SOS" vs "SOS Matrix" could be determined from a parameter to a "SOS" object. I don't know enough about the underlying theory to say.

[blegat]

@chriscoey I understand that all this might change a lot in the future but I would like to have one syntax that I know will work for some time to put it in the slides at the JuMP meetup :-P
It seems to me that @SDconstraint is safe since it does not use the "set inclusion" interface. If this macro disappears in the future, users won't be surprised that the PolyJuMP syntax has changed too