-
Notifications
You must be signed in to change notification settings - Fork 33
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
Function for checking boundedness #605
Comments
We should add this function for all set types. Usually this will be a constant function (e.g., |
Has there been news on this by any chance? I could definitely still use such a function. No pressure 😉 In reference to the point about n+1 constraints, this is the minimum number of constraints, no? So seeing any number less than n+1 tells you the polytope is unbounded, but any number higher doesn't tell you anything. |
Yes, this is only a necessary and very weak (but also very efficient-to-check) condition. Now that I think about it, I am wondering if we should allow this check to be performed for If you are not interested in efficiency, I can add the naive approach mentioned above (2n LP checks, where n is the dimension) in the next week. There might actually be no fundamentally better way (a quick internet search gave no result). |
Perhaps the boundedness function should be written for a vector of constraints rather than a set type, as you suggest. That way, it could both be used on
Well, one is always interested in efficiency... but if there's no other way, then so be it! As for naming, how about simply Also, since we are using the word bounded so much, I couldn't help but think about this in the context of bounds checking. Now it occurs to me that perhaps you can have the best of both worlds: be able to check boundedness without sacrificing performance where boundedness should be assumed. You could write the check in to "risky" areas, decorating calls like: |
👍
I simply do not know 😃
My question was about the convenience function (which takes a list of constraints and gives you the appropriate set type).
Hm, I would not hijack the existing macro because it serves a different purpose, but interesting idea! |
Ah I see, sorry. Rereading your previous comment, I'm not sure such a function is strictly necessary, especially since it is inherently type unstable. That said, the functionality could become part of a general polytope function like the one proposed in #875 |
#605 - Function for checking boundedness
In #956 @schillic added the We should note that There is not yet the option to check that a new instance of If one is not sure that the polyhedra being used are bounded, there are some alternatives:
|
🎉🎉 A |
This option came in #978 ( |
Examples in the construction: julia> HPolytope()
HPolytope{Float64}(HalfSpace{Float64}[])
julia> HPolytope(Array{HalfSpace{Float64},1}(), check_boundedness=true)
ERROR: AssertionError: the polytope is not bounded
Stacktrace:
[1] #call#40 at /Users/forets/.julia/dev/LazySets/src/HPolytope.jl:31 [inlined]
[2] Type at ./none:0 [inlined]
[3] #HPolytope#42 at /Users/forets/.julia/dev/LazySets/src/HPolytope.jl:39 [inlined]
[4] (::getfield(Core, Symbol("#kw#Type")))(::NamedTuple{(:check_boundedness,),Tuple{Bool}}, ::Type{HPolytope}, ::Array{HalfSpace{Float64},1}) at ./none:0
[5] top-level scope at none:0 Perhaps we could improve the error message suggesting to construct an Example after construction: julia> isbounded(HPolytope())
true
julia> isbounded(HPolytope(), false) # use kwarg use_type_assumption
false |
Add a function that checks if an
HPolytope
(and anAbstractHPolygon
) is bounded.An efficient but only necessary check is to look at the number of constraints. In n dimensions you need at least n+1 constraints.
A naive approach could be to ask for the support vector in the positive and negative unit directions.
The text was updated successfully, but these errors were encountered: