List of known bugs v4.02

[djagt]

dpvar/@dpvar/subsasgn:
When assigning a particular element of a particular field of a dpvar class object, the function "subsasgn" called the function "set", which we do not have for dpvar class objects. The function was adjusted to avoid the explicit use of "set".

[djagt]

sossolve:
In the last update to "sossolve", a check was added, setting the value of an object "feasextrasos" to 0 if a problem is found to have obviously infeasible inequality constraints. However, the value of "feasextrasos" was not specified if no inequality constraints appeared in the problem, producing an error. This has been resolved, setting a default value "feasextrasos=1" before processing the inequality constraints.

[djagt]

sossolve:
When calling "sossolve" with solvers 'sdpt3', 'sdpnal' and 'sdpnalplus', the function checked whether any SOS variables are present in the problem by verifying "K.s(1)~=0", where the field "K.s" contains the size of each SOS variable in the problem. However, a lack of SOS variables results in an empty field "K.s", rather than the first element being equal to zero, producing an error. A check has been added to ensure the field is not empty, solving the issue. However, the "K.s(1)~=0" is still included as well, as an SOS variable of size 0 would certainly produce an error as well, though I don't think such a variable can actually be implemented.

[djagt]

internal/sosprogramming/sosconstr:
Objects of type "polynomial" are converted to "dpvar" class objects to account for the updated "addextrasosvar" implementation is "sossolve". However, in determining the decision variables in the program, "prog.decvartable" was called rather than "sos.decvartable", which has now been fixed.

[djagt]

internal/sparsityandstructure/mat:
The "Sedumi2Mosek" conversion function requires "mat.m" to run, which is included with e.g. Sedumi. However, this means conversion would not work if the user did not have Sedumi, so I have included "mat.m" as part of SOSTOOLS now as well.

[djagt]

internal/sparsityandstructure/sprepmat:
The function previously required the user to specify the amount of times to repeat the array in each direction (rows and column) separately. It has now been updated to allow these dimensions to be specified using a single 1x2 array, so that "sprepmat(A,m,n)=sprepmat(A,[m,n])".

[djagt]

sosgetsol:
The function previously required the decision variables to be specified as polynomial or dpvar class objects. It has now been adjusted to allow a cell of variable names (or a single variable name) to be passed as well (when using the pvar/dpvar implementation).

[djagt]

dpvar/@dpvar/subsref:
The function previously allowed linear indices to a dpvar object to be specified only as an mx1 or 1xm array, always returning an mx1 array as output. The function has been updated to allow linear indices to be specified as an mxn array, producing a dpvar output with the same dimensions as the indices.

[djagt]

custom/findbound:
Previously, when the function was called with a 'polynomial' class object for the equality or inequality constraints, an error occurred if the "degmat" field of this polynomial was empty. In particular, the function was unable to establish a maximal degree of the polynomial in this case, resulting in issues. This problem has been resolved, setting the maximal degree to zero in this case.
In addition, a 'dpvar' implementation of the code has been added, allowing the function for which to find a bound to be specified as a 'dpvar' class object. Note, however, that in general it does not make sense for the function to bound to have decision variables itself.

[djagt]

multipoly/@polynomial/horzcat:
multipoly/@polynomial/vertcat:
In "horzcat.m" and "vertcat.m", when both inputs to concatenate are empty polynomials, the function would previously just return one of the polynomials. However, empty objects may still have a nonzero row dimension, or a nonzero column dimension, in which case the row or column dimension of the output would have been incorrect. For example, vertically concatenating a 1x0 object and a 2x0 object, a 3x0 object would be expected, but the "vertcat" function would previously return either the 1x0 or the 2x0 object. This issue has been resolved, ensuring that the row dimension of the output of "vertcat" matches the sum of the row dimensions of the input, and similarly for the column dimensions in "horzcat".
NOTE: If only one of the input polynomials is empty, the function still does not check that the column dimensions (in "vertcat") or row dimensions (in "horzcat") of the two inputs match. That is, [(zeros(0,10); [1,x]] for some 'pvar' object x would simply return [1,x]. I'm not quite sure if this feature is useful, or if it may lead to issues, so I have left it as is for now.

[djagt]

multipoly/@polynomial/times:
Small added feature: The function has been updated to allow outer products of vector-valued polynomials to be computed, so that e.g. [1, x].* [y; z] returns [y, xy; z, xz], and [1; x].* [y, z] returns [y, z; xy, xz].
NOTE: The outer product [1; x].* [y, z] can (and could previously) also be computed using mtimes, e.g. calling [1; x] * [y, z]. However, calling [1, x] * [y; z] computes the inner product y+x*z.

[djagt]

multipoly/@polynomial/subsref:
multipoly/@polynomial/private/PV_subsasgn_1idx:
multipoly/@polynomial/private/PV_subsasgn_2idx:
There was an issue with using logical indices for "subsasgn" of polynomial objects, as the function "PVsubsasgn_1idx" expected the size of the right hand side to match the total number of logical indices, rather than the number of "true" indices. This has been resolved.
In addition, "subsref" and "PVsubsasgn_2idx" have been updated to also allow separate row and column indices to be specified as logical indices in extracting and setting elements of polynomial objects.

[djagt]

sossolve:
When calling "sossolve" with solver 'sdpa', the output "info.phasevalue" can assume values 'pUNBD' and 'dUNBD', which the "sossolve" function could not process. The function has been updated to also allow these outputs, indicating that the primal (pUNBD) or dual problem (dUNBD) is likely unbounded.

[djagt]

internal/processing/proj3:
The function previously returned an error when non-integer values were used, even if a rational output was possible. This has been fixed, producing an error only in cases where no rational value can be found up to the tolerance of the built-in Matlab function "rat".

[djagt]

custom/findsos:
The pvar/dpvar implementation of the "findsos" function with "flag='rational' was simply a copy of the syms implementation, producing an error as the function "expand" does not exist for polynomial class objects. This has been resolved. In addition, some more checks have been added to avoid rough exists/errors when the input function has non-integer coefficients.

[djagt]

sossolve:
The sedumiwrap for solver 'sdpa' does not currently accept fields "K.q" and "K.r". If these are zero, however, the function should be able to run. A check has been added to determine whether these values are zero, and remove them from "K", so that the sedumiwrap can be properly run.

[djagt]

custom/findsos:
If the function was called with more than 2 outputs, but the function terminated prematurely due to e.g. an SOS decomposition not being possible, an error would be thrown as the last two function outputs were not specified. This has been resolved by also initializing the additional outputs as empty fields when the function terminates prematurely.

[djagt]

addsostools:
The function had not yet been updated for the SOSTOOLS 400 release, failing to add the subfolders in "/internal" and the "/dpvar" folder to the path. This has been resolved.