List of known bugs v4.01

[djagt]

dpvar/@dpvar/display:
The function used "sum(A,'all')" to take the sum of all elements of "A". However, this functionality was only introduced with Matlab R2018b. Each occurrence has been replaced with "sum(sum(A))", to allow for proper functioning with earlier versions of Matlab.

[djagt]

sosprogram:
The function checks whether an SDP solver is installed, but failed to include Mosek in this check. Since this solver is also supported, the function has been updated to check for availability of Mosek as well.

[djagt]

custom/findsos:
The function tried to compute "sqrtm(double(Q))", which produced an error when Q was sparse. The function now computes "sqrtm(full(double(Q)))" instead, fixing the issue.

[djagt]

dpvar/@dpvar/dpvar.m
Update for enhanced functionality:
The function now allows a cell of strings as input, so that e.g. y=dpvar({'c1','c2;'c3','c4'}) returns a dpvar object y=[c1,c2;c3,c4], where c1,...,c4 are decision variables.

[djagt]

dpvar/@dpvar/
Update for enhanced functionality:
A "sum" and "trace" function has been added to the @dpvar folder, so that the sum of matrix-valued dpvar object along rows, columns, or the diagonal can now be easily computed.

[djagt]

dpvar 'Mineq' Update:

There was an issue with the processing of inequality constraints on matrix-valued functions using the dpvar implementation, particularly when calling "sosmatrixineq" with the 'Mineq' option. To fix this, the functions "getequation", "sosconstr" and "sossolve" have been adjusted, allowing 'Mineq' constraints to be imposed on dpvar class objects. The updated files also solve some issues with the syms implementation, though errors still occur in some edge cases.

sossolve:
Previously, imposing inequality constraints on matrix-valued dpvar objects using the 'Mineq' option produced an expression in the program structure that could not be properly processed. Therefore, "getequation" and "sosconstr" have been adjusted to return a different format when 'ineq' constraints are imposed. An alternative version of the "addextrasosvar" subroutine in "sossolve" has now been implemented for the dpvar case, to process the 'ineq' constraints in the new format.
In addition, a check has been implemented to avoid an error for the syms implementation. In particular, in the "addextrasosvar" subroutine, an SOS variable S(x) is constructed to implement the constraint F(x)=S(x) for a given polynomial F(x). In doing so, a minimal basis Z(x) of monomials is established such that S(x) is SOS in Z(X) and can match all terms in F(x). However, if F(x) contains only odd degree monomials, this minimal basis will be empty, producing an error. To avoid this, a check has been implemented to stop the solving process if the monomial vector Z(x) is found to be empty, warning the user that the problem is infeasible in this case.

internal/sosprogramming/getequation:
For a matrix-valued dpvar class expression, "getequation" produced a separate set of monomials for each element of the matrix, discarding monomials that did not contribute. However, for constraints of type 'ineq', the resulting "prog.expr" format returned by "getequation" did not allow for proper processing/conversion of the constraint in "sossolve". The function has been adjusted to take an additional optional input 'ineq', so that, when this option is passed, "getequation" returns a single set of unique monomials to be used for all elements of the matrix-valued object.
In addition, in lines 309 and 325 of the code, an element-wise transpose of a sym expression was computed. However, this transpose does not appear to produce the expected result, likely due to an update in the symbolic toolbox, producing an error. The transpose has now been excluded, avoiding the error, although other problems may still be present.

internal/sosprogramming/sosconstr:
The function "sosconstr" has been adjusted to match the update to "getequation" for the dpvar implementation, passing the constraint type to "getequation" when processing dpvar class objects.
In addition, the function has been updated to convert variables of type "double" to "sym" class objects if the sym implementation is used, and "dpvar" class objects otherwise. Furthermore, expressions of type "polynomial" are also converted to class "dpvar" objects before calling "getequation". This is because the updated "addextrasosvar" subroutine in "sossolve" cannot distinguish between constraints imposed using "dpvar" and "polynomial" expressions, and so both expressions must be implemented in the same format. However, in the reversionary implementation where decision variables are implemented as 'pvar' objects, the implementation is no longer truly reversionary, and computation time may be increased.