3 ms·
We compared our OSQP solver to other general-purpose solvers. That's why we chose GUROBI and Mosek. There are also examples of control problems for which it is
by sidereus 9y ago
We compared our OSQP solver to other general-purpose solvers. That's why we chose GUROBI and Mosek. There are also examples of control problems for which it is possible to design very efficient tailored methods. However our point is not to compare our solver to specific methods for certain classes (like libsvm).
In the benchmarks we are comparing examples with randomly generated data because we were interested in ~1400 problems in a range from 100 to 10 million nonzeros. The examples are not just random QPs, but data are generated in a reasonable manner and they have the same structure as problems people would actually solve in practice. In the arXiv paper we described in detail how we generated and checked optimality for the examples.
As mentioned in the README of the repository that you checked out (https://github.com/oxfordcontrol/osqp_benchmarks https://github.com/oxfordcontrol/osqp_benchmarks) we used the conversion scripts from here: https://github.com/YimingYAN/QP-Test-Problems https://github.com/YimingYAN/QP-Test-Problems
If you know better ways to convert the Maros problems (or other QP/LP benchmarks) to mat files or other formats compatible with Python, please let me know. I would be happy to try them.
- tmyklebu 9y ago> We compared our OSQP solver to other general-purpose solvers. That's why we chose GUROBI and Mosek. Your computational results don't support calling OSQP general-purpose. OSQP does okay on the easy problems you randomly generate, but this doesn't seem to generalise---OSQP gives results on a bunch of the Maros-Meszaros problems that markedly disagree with previously published work. > However our point is not to compare our solver to specific methods for certain classes (like libsvm). You may not want to compare against libsvm's solver (though I imagine you look pretty good on the problems you're generating) but there is also a lot of data available at the libsvm webpage. This data might serve as a more representative SVM testbed than the random easy instances you're creating. > In the benchmarks we are comparing examples with randomly generated data because we were interested in ~1400 problems in a range from 100 to 10 million nonzeros. The examples are not just random QPs, but data are generated in a reasonable manner and they have the same structure as problems people would actually solve in practice. The "random QPs" and "random equality QPs" do seem to be "just random QPs." I get cond(A^T A) ranging between 1.3 to 1.7 with your Lasso problem generator. These instances are going to be incredibly easy to solve, even with very naive algorithms. (Separately, why not eliminate the 'y' variable from your formulation? You get a formulation that's about 100 times smaller, and you should see a corresponding speedup.) > In the arXiv paper we described in detail how we generated and checked optimality for the examples. Yes, you check for a bunch of residuals' infinity-norms being smaller than 1e-3. But you get results that differ markedly from the other solvers' results. To me, that raises the question of whether the 1e-3 test is appropriate. > As mentioned in the README of the repository that you checked out (https://github.com/oxfordcontrol/osqp_benchmarks https://github.com/oxfordcontrol/osqp_benchmarks) we used the conversion scripts from here: https://github.com/YimingYAN/QP-Test-Problems https://github.com/YimingYAN/QP-Test-Problems > > If you know better ways to convert the Maros problems (or other QP/LP benchmarks) to mat files or other formats compatible with Python, please let me know. I would be happy to try them. Well, QPS is a punch-card style input format like MPS. Like MPS, I imagine you can write a parser for it in a couple of highly unfulfilling hours.