schillic on gh-pages
build based on 916cac4 (compare)
mforets on bump_CI
mforets on master
update docs (#160) (compare)
schillic on gh-pages
build based on 17d34d1 (compare)
mforets on bump_CI
update docs (compare)
mforets on mforets-patch-2
schillic on gh-pages
build based on af50bc3 (compare)
linear_map
inverts again
S
directly
S
to linear_map
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