List of known bugs v4.00

[djagt]

dpvar/ @dpvar/ subs:
Issue in the case where substitution returns a constant. Previous implementation resulted in the dpvar coefficient matrix to be specified by a polynomial class object, resulting in errors. The check "isdouble(...)" has been replaced by "isa(...,double)", resolving this issue.

[djagt]

custom/ findbound:
The function relied on 'findsym' from Matlab symbolic toolbox, which has been removed in the latest version(s). The function was adjusted to use 'symvar' now, resolving the issue.

[djagt]

sospsimplify:
The function extracted rows of A which contain exactly 2 nonzero elements, not relying on any tolerance, but then extracted associated nonzero columns with a tolerance, producing less column indices than expected. This has been resolved by removing the tolerance in the extraction of column indices as well.

[djagt]

dpvar/ @dpvar/ subsref:
The function produced incorrect results upon calling it with linear indices. This issue has been resolved.
Note: Right now, linear indexing will always produce a column vector, independent of how the indices are passed.

[djagt]

custom/ findbound:
The function used 'num2cell' when substituting the produced values of the 'sym' variables. However, this produces an error if the variables are 'pvar'. The code was adjusted to check for the class type of the variables, avoiding 'num2cell' if these are 'pvar'.

[djagt]

sossolve:
There was an error when the function was called with options and a field 'options.params' was specified but no 'options.params.tol' was specified. The function did not explicitly check if a tolerance was specified, only if a field 'options.params' was specified. Currently solved by adding default tolerance in case 'psimplify' is used. It's possible, however, that other parts of the code may also fail if no 'options.params.tol' field is specified, but so far I haven't encountered any errors.
Also, I added the option to specify 'options.simiplfy=0' to turn off 'psimplify'.

[djagt]

sospolymatrixvar:
There was an error when using the 'pvar' option. The function 'sospolyvar' was then called with 3 arguments, the third of which specifying the 'pvar' option. However, 'sospolyvar' takes this option only as its fourth argument. I corrected to pass an empty field as third argument and 'pvar' as fourth, solving the problem. However, maybe 'sospolyvar' needs to be adjusted instead, to allow 'pvar' to be specified as third argument as well, since only the first two arguments of 'sospolyvar' are actually mandatory.

[djagt]

internal/ sosprogramming/ getequation:
Using the 'syms' implementation, the function kept producing errors concerning missing closing brackets ']'. There were two main issues:

1. The symbolic toolbox no longer allows vertical concatenation to be used in expressions evaluated in the symengine, e.g.

evalin(symengine,'[x1;x2]');

does not work. This can be fixed using 'str2sym' instead:

str2sym('[x1;x2]');

2. The 'vartable' was constructed by combining the original 'vartable' and the 'varmat', as

vartable = evalin(symengine,[vartable(1:end-1),',',varmat(2:end)]);

However, where 'vartable' appears to be a string of horizontally concatenated variables with opening and closing brackets '[' and ']' (e.g. '[x1,x2]'), 'varmat' appears to be a string of vertically concatenated variables without opening or closing brackets (e.g. 'Mvar1;Mvar2'). Currently, this is fixed by replacing semicolons with commas, and adding a closing bracket:

vartable = evalin(symengine,[vartable(1:end-1),',',strrep(varmat(1:end),';',','),']']);

However, maybe 'varmat' should just be a string of horizontally concatenated variables with opening and closing brackets in the first place?

[djagt]

dpvar/ @dpvar:
Several dpvar class functions rely on the 'vec' function that comes with certain solvers (e.g. SeDuMi). However, some people may not have this function. Maye it should be included with SOSTOOLS as well?

[djagt]

sossetobj:
The function did not allow dpvars to be specified unless their 'varname' field was of size [0,0], so that no independent variables would be included in the objective. However, the second dimension of the 'varname' field should always be 1, so I adjusted to verify only the first dimension to be zero.
In addition, the 'sos.objective' field produced in the 'dpvar' case was a row vector, producing errors later on (in 'sossolve'). This has been fixed to now produce a column vector.

[djagt]

sosineq:
The function allows an interval to be specified when the 'syms' implementation is used. However, in the 'dpvar' case, this interval is ignored, without warning the user. The function has been adjusted to allow [-Inf,b] and [a,Inf] intervals to be specified, and return an error if a finite interval [a,b] is specified, in the 'dpvar' case.

[djagt]

sosprogram:
Currently, the dpvar class function 'length' returns the number of rows of the dpvar object. As a result, the value

sos.var.idx{1} = length(decvartable)+1;

in the 'sosprogram' function was set to 2 if 'decvartable' had only one row, even if it included multiple decision variables. This has been fixed by instead computing

sos.var.idx{1} = length(sos.decvartable)+1;

returning the correct number of decision variables. However, we may need to adjust the dpvar 'length' function to return the maximal array dimension rather than the number of rows.

[djagt]

dpvar/ @dpvar/ length:
This function previously returned the number of rows of the dpvar object. It has been adjusted to return the maximal array dimension instead.

dpvar/ @dpvar/ dpvar:
The method previously did not allow a dpvar to be specified as e.g. "y=dpvar('x')". The method has been updated to include this functionality.