-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zero Volume for 14D polytope #69
Comments
Thank you for reporting this error. I confirm that zero volume is computed using commit f981f43. The reason appears to be a missing Lines 1304 to 1306 in f981f43
The consequence of this missing branch is that if the optimization does not succeed, then the value of 0 is used for all bounds, because this is how the bounds are initialized within that function: Line 1296 in f981f43
Running the lines of code from that area in >>> sol
{'status': 3,
'x': array([-6.37083e+07, 4.27238e+07, 4.38813e+06, -1.10456e+08,
-1.77619e+08, -3.76229e+07, -1.46560e+08, -1.02404e+07,
-1.70243e+08, -1.55426e+08, -3.99459e+08, -6.16730e+07,
3.36853e+05, -7.07112e+08]),
'fun': -707111604.4008977} and when using >>> sol
{'status': 3, 'x': None, 'fun': None} Quoting from the documentation of the function
and the documentation of the function
which is relevant to the lines: Line 107 in f981f43
Lines 115 to 116 in f981f43
So:
I had been aware that unbounded polytopes are currently unsupported by the package In conclusion, the simplest approach for now seems to be to raise an exception from within the function Regarding the polytope given above (#69 (comment)), if indeed it is unbounded, then its volume is infinite. |
Thank you very much for the exhaustive answer. Indeed, the problem was unboundend, sorry for the confusion, I tried to prepare a minimal working example which ended up being too minimal as the bounds stayed in the pulp variable declaration. I now created a file including bounds which results in a nonzero volume, however a different value is computed each time the script is executed. Is this behavior problem specific and/or is there a way to change the solving algorithm or it's parameters in order to better "suit" this problem? |
Volume algorithm implemented in polytope package is a randomized algorithm that tries to give an estimate of the volume. It might be unreliable especially in higher dimensions. You can try to increase the number of samples on the following line (this number should increase exponentially with the dimension to get similar accuracy): Line 1467 in f981f43
to improve accuracy. This should reduce the variation but there will still be some variation due to randomness. Increasing the samples will slow down the computation. We currently don't have an alternative deterministic volume computation algorithm implemented. |
Thank you @alhaas for the example. Thank you @necozay for the comment. I fixed the bug due to the missing I added a parameter So now the function I confirm that the example code given above (#69 (comment)) returns varying volume values in each run. Nonetheless, some of the values computed by different runs are: Using commit 5fb8a70 and changing the example's (#69 (comment)) last lines to: p = pt.Polytope(A, b)
pt.volume(p, nsamples=10**6) # the default value is 10**4
print(p.volume) returns the value |
Thanks again for the feedback, from my side the issue is solved. If possible, maybe it would be an enhancement for the future to also give a seed to the |
Thank you for the suggestion @alhaas. I implemented this approach by adding in commit 99e2090 a parameter named In more detail, the randomness within the function Line 1501 in 7f59645
The documentation of the function
The function
The function So the line of code linked-to above has been replaced by the line: Line 1562 in 99e2090
where AsideThe CI tests for Python 2.7 for commit 99e2090 failed, because the function The reason is that the last |
As of commit 9ee3f96, support for Python 2.7 has been removed, and also support for Python 3.5 and 3.6 has been removed. For motivation, please read the commit messages on branch The latest |
As of commit a23ddcf, the changes discussed above have been merged to the mainline branch, which addresses this issue. Support for unbounded polytopes is an orthogonal issue, and will be considered in a separate issue that I plan to open in time. |
Dear polytope devs,
I hope this is the right place for this. I have created an example similar to the one in the tutorial for a convex polytope in H-representation, however it gives me a volume of 0.0 and also, there is no warning in case the dimensions do not match. I think I am missing something here, as the same problem gives a nonzero volume with the Volesti package in R.
My Python version is 3.7.6.
The text was updated successfully, but these errors were encountered: