mforets on 2506
add generic conversion to HPoly… (compare)
mforets on master
Update VREP.md (compare)
mforets on gh-pages
build based on c16c1998 (compare)
mforets on tests_seed
mforets on master
set random seed (#2508) (compare)
mforets on tests_seed
set random seed (compare)
mforets on gh-pages
build based on 83016be0 (compare)
mforets on mforets-patch-2
Update .travis.yml (compare)
mforets on bump_julia_CI
mforets on bump_julia_CI
mforets on 2310
there should be an option to pass S directly
linear_map
but would not use it
S
minkowski_difference
the second argument is a (again: constant) BallInf
. maybe that can be exploited, but from the code for minkowski_difference
i don't see howminkowski_difference
of two zonotopes is again a zonotope (not in our current implementation, but it should be easy to add a method for that; this is JuliaReach/LazySets.jl#586), and the linear map of a zonotope is again a zonotope. the "problematic" operation here is the intersection with a BallInf
, which does not preserve "being a zonotope." if you are willing to pay the price of an overapproximation to a zonotope at this point, you would get rid of the remove_redundant_constraints
and the linear_map
would be cheap as well. but the intersection
then becomes more complicated (i think there is no way around some bottleneck :P)
for the
minkowski_difference
I know that I solve #constraint linear programs (therefore, it is linear in the number of constraints)
no, the implementation of minkowski_difference
performs m
support-function queries, which in your case are applied to a BallInf
(which is very cheap)
minkowski_difference
is fast
HPolytopes
so even though the Zonotopes
option sounds really interesting, I cannot use it for my current issue.linear_map
to pass the matrix S
directly would be exactly what I was looking for since if I can get rid of the performance penalty of computing the inverse every iteration.
minkowski_difference
) until the intersection
"for free"
HPolytope
and have to use the slower methods