Closed RoyiAvital closed 7 months ago
The issue is that CVX sets MSK_DPARINTPNT* termination tolerances to 0.0, which should be avoided, and that even the "default" precision sets some values that are not Mosek defaults.
A sensible solution would be that "default" precision keeps default Mosek tolerances, "low" divides them by C and "best" multiplies by C, for some C, if at all necessary.
How come other solvers handle this? I think @mcg1969 explained the logic in that mode - Let the solver say when he think it is done.
Anyhow, even for tolerance of 0
I wouldn't expect MOSEK
to return NAN
.
Different solvers have different parameters and different interpretations.
If you want to "Let the solver say when he think it is done." then the way to do it in Mosek is not to change parameter settings from their default values.
Nan is understandable if the solver finds no solution.
This is exactly what doesn't make sense.
Let's say that for the default the solver executed 100 iterations and got to the accuracy required.
Then for lower tolerance I'd expect it will do the same exact 100 iterations and then few more, in order to achieve lower tolerances. But in any case I don't expect it to infer there is no solution or return NaN
. At worse case it should say couldn't reach the tolerance, this is the best effort solution.
It is more or less like you say if you use decreasing but positive tolerances. Tolerances equal to zero are simply meaningless from the point of view of Mosek termination criteria and result in unspecified behavior, which you experience. Sorry it is not handled better, like by a warning or error but that's how things are now.
Sorry that nobody ever responded to this; we don't look at this repo much. For the benefit of others who come here, please visit https://ask.cvxr.com/ for questions about DCP.
I wrote about failing to solve a CVX model with Mosek in - Mosek Fails Where SDPT3 Works - Least Squares with Semi Definite Constraint.
I narrowed the problem that
Mosek
fails when CVX precision is set to high bycvx_precision('best');
.Any idea why? How could that be fixed in case of high accuracy is needed?