Re: Error in using lp2poly
Posted: 27 Nov 2019, 11:44
Thank you gawrilow.
I confirm being able to get the optimal MIP solution using the workaround you provided.
For this very same problem (.lp file as attached in my immediately previous message), I was trying to project the solution space into the space of pure binary variables only (_e*) variables in the .lp file.
I followed the steps as specified in https://polymake.org/doku.php/user_guid ... timization
Specifically, I ran the following code via a script:
The only difference between my code and the code example provided in https://polymake.org/doku.php/user_guid ... timization is that in my case, I would like to project into the space of the first 10 variables (hence the numbering 1, 2, through 10 and this ordering is obtained as the ordering in the "Bounds" section in the .lp file) since these alone are the binary 0/1 integer variables.
On running this script, my computer essentially hangs and I have to restart my machine after 30 minutes or so.
However, I cannot think of a mathematical reason for why the computation should be so expensive. If I understand the projection algorithm correctly, it should essentially enumerate 2^10 = 1024 points, (since there are 10 binary integer _e* variables in the .lp MIP file), discard the infeasible points and construct the polytope over these 10 dimensions.
Now, the very first constraint of the .lp file is:
So, we don't even have to enumerate all 1024 point. We only have to enumerate a much smaller number of points where the sum of the coordinates is 4. Then, over these much smaller points, one would have to verify that the continuous variables can be set without causing infeasibility to them.
Would it be possible to know at which step polymake encounters the hotspot in the above computation? It appears to me that getting the facets of the feasible integer space should be a reasonably fast operation/computation in this case because the number of feasible integer points should be substantially lesser than 1024.
Thanks again for your continued support.
I confirm being able to get the optimal MIP solution using the workaround you provided.
For this very same problem (.lp file as attached in my immediately previous message), I was trying to project the solution space into the space of pure binary variables only (_e*) variables in the .lp file.
I followed the steps as specified in https://polymake.org/doku.php/user_guid ... timization
Specifically, I ran the following code via a script:
Code: Select all
use application "polytope";
use vars qw($f $p $q $s);
$f=lp2poly('problemIP_polymake.lp');#lp file from cplex. Should be OK
$p = new Polytope<Rational>($f);
$q = projection($p, [1,2,3,4,5,6,7,8,9,10]);#projects p into space of 1st through 10th variables.
$s = new Polytope(POINTS=>$q->LATTICE_POINTS);
print_constraints($s);
On running this script, my computer essentially hangs and I have to restart my machine after 30 minutes or so.
However, I cannot think of a mathematical reason for why the computation should be so expensive. If I understand the projection algorithm correctly, it should essentially enumerate 2^10 = 1024 points, (since there are 10 binary integer _e* variables in the .lp MIP file), discard the infeasible points and construct the polytope over these 10 dimensions.
Now, the very first constraint of the .lp file is:
Code: Select all
C1_0: _e0_1#0 + _e0_2#1 + _e0_3#2 + _e0_4#3 + _e1_2#4 + _e1_3#5
+ _e1_4#6 + _e2_3#7 + _e2_4#8 + _e3_4#9 = 4
Would it be possible to know at which step polymake encounters the hotspot in the above computation? It appears to me that getting the facets of the feasible integer space should be a reasonably fast operation/computation in this case because the number of feasible integer points should be substantially lesser than 1024.
Thanks again for your continued support.