cvxopt 1.2.0 bug

[rebeckawinqvist]

I keep encountering an error when I run Tulip with the latest version of Polytope when using the 1.2.0 version of cvxopt. The error disappears when using cvxopt 1.1.8. This is an example of the output that I receive: rebwin@rebwin-Lenovo-Yoga-2-13:~/tulip-control-master/examples$ python continuous.py GLPK Simplex Optimizer, v4.65 4 rows, 3 columns, 8 non-zeros

• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 3: obj = -5.000000000e-01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 8 rows, 3 columns, 16 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 3: obj = -5.000000000e-01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.000000000e+00 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.000000000e+00 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.100000000e+00 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.100000000e+00 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.000000000e-01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 6 rows, 2 columns, 6 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 1: obj = -1.000000000e-01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND GLPK Simplex Optimizer, v4.65 4 rows, 3 columns, 8 non-zeros
• 0: obj = 0.000000000e+00 inf = 0.000e+00 (1)
• 3: obj = -5.000000000e-01 inf = 0.000e+00 (0) OPTIMAL LP SOLUTION FOUND Traceback (most recent call last): File "continuous.py", line 68, in cont_partition = prop2part(cont_state_space, cont_props) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/tulip/abstract/prop2partition.py", line 119, in prop2part dummy = region_now.diff(cur_prop_poly) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/polytope/polytope.py", line 754, in diff return mldivide(self, other) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/polytope/polytope.py", line 1365, in mldivide Pdiff = mldivide(Pdiff, poly1, save=save) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/polytope/polytope.py", line 1380, in mldivide P = region_diff(a, b) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/polytope/polytope.py", line 1977, in region_diff N = len(reg) File "/home/rebwin/anaconda3/envs/pythonpoly/lib/python3.6/site-packages/polytope/polytope.py", line 675, in len return len(self.list_poly) AttributeError: 'Region' object has no attribute 'list_poly'

It seems like the attribute 'list_poly' is never initialized.

[slivingston]

I reproduced the error locally, and now I am investigating.

[slivingston]

My hypothesis is that version 1.2.0 of cvxopt has a bug in its handling of solver options when provided as an argument to the solver-specific lp function, which is a new feature in version 1.2.0 of cvxopt. I am trying to make a minimal demonstrating example, but meanwhile, a workaround is

diff --git a/polytope/solvers.py b/polytope/solvers.py
index fa9e71a..97e02e0 100644
--- a/polytope/solvers.py
+++ b/polytope/solvers.py
@@ -40,7 +40,7 @@ try:
     installed_solvers.add('glpk')
     # Hide optimizer output
     cvx.solvers.options['show_progress'] = False
-    cvx.solvers.options['glpk'] = dict(msg_lev='GLP_MSG_OFF')
+    cvx.glpk.options['msg_lev'] = 'GLP_MSG_OFF'
 except ImportError:
     logger.warn(
         '`polytope` failed to import `cvxopt.glpk`.')

[slivingston]

I created a bug report at https://github.com/cvxopt/cvxopt/issues/120

[slivingston]

To avoid having to wait on upstream to accept the bug report etc., I recommend that we change our usage as shown above.

@necozay @johnyf thoughts?

[necozay]

I’m fine with the proposed workaround. Thanks.

Necmiye

On Jul 1, 2018, at 11:20 PM, Scott C. Livingston notifications@github.com wrote:

To avoid having to wait on upstream to accept the bug report etc., I recommend that we change our usage as shown above.

@necozay @johnyf thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.