linear programming if `cvxopt` present but `cvxopt.glpk` absent about polytope HOT 5 CLOSED

If I recall it right, that order is intentional. There were TuLiP examples for which cvxopt's native LP solver was getting stuck. I don't recall experiencing that with scipy. I think @ajwagen has done some benchmarking before deciding on that order. @ajwagen do you have any comments on how scipy solver compares with native LP solver of cvxopt (speed, reliability, etc.)?

from polytope.

A possibly relevant issue is: tulip-control/tulip-control#82

from polytope.

The benchmark results mentioned in #2 (comment) suggest that the Python LP solver of cvxopt is about 5 times slower than cvxopt.glpk.

from polytope.

See also #15 .

from polytope.

As reported for cvxopt.coneprog.conelp (131 sec) in tulip-control/tulip-control#82 (comment), is slower than scipy (94 sec).

Looking at the source of conelp, it appears to depend on a C extension module called blas (e.g., on this line, by importing blas, and via the misc module.

So the default of using scipy appears to be a better choice, unless GLPK is available.

Feedback via email from @ajwagen confirms these findings in the general case. In summary:

• 1K optimizations with same matrices for each too:
  1. 2 variable case:
  • scipy: 7.856 sec
  • cvxopt without GLPK: 22 sec
  2. 10 variable case:
  • scipy: 43.579 sec
  • cvxopt without GLPK: 35 sec
• scipy seems numerically more stable than cvxopt without GLPK.
• scipy solves both examples/continuous.py and examples/pwa.py faster than cvxopt without GLPK (earlier versions of those examples, though their numerics have remained about the same through time).

Given these findings, that scipy is a required dependency, that cvxopt is now easier to install, and that a choice between solvers is available (#17), tthere is no reason to use cvxopt without GLPK.

from polytope.