Open tcunis opened 4 years ago
I don't think it's necessary to enlarged the interface of the SOSFactory, it's possible to from the constraints and the decisions variables to know which ones are linear and bilinear, it's going to be an additional step inside the definition of the constraint. In this way, there is no need for the user to specify which variables are linear and bilinear but from the programming perspective, there is a necessity to know the current decision variables when defining the BilinearConstraint
I do not understand what you mean with
it's going to be an additional step inside the definition of the constraint
I am starting to think the best option would be to wrap the polynomial objects from SOSFactory
(i.e., the polynomial types defined by the underlying SOS toolboxes) and thus to keep track of the operations.
As of today, the BiSOS problem definition relies on the user to specify the list of decision variables in which the constraint is linear or bilinear; e.g., the line
(from demo.m) registers the constraint
s2*(V-g) - gradV*f is SOS
which is lineargradV
and bilinear inV
,g
, ands2
, as specified in the 4th and 5th argument, respectively.Instead, it would be convenient to extra the information which variables enter (bilinearily) into the constraint directly from the left and right-hand side polynomials. This might imply an increased dependency on the chosen polynomial implementation; the necessity of an enlarged interface of the SOSFactory; or, in avoidance of either, an in-house implementation of polynomial objects.