there should be an option to pass S directly
maybe our messages crossed
because you just pass it to
linear_map but would not use it
because you know it's invertible and the inverse is
S
hmm this is related but not the same?
we didn't speak about passing the inverse matrix there
where you already know the inverse
this issue was some logic (my logic) broken
@ueliwechsler: it seems to me be that in your
however, your inputs are zonotopes,
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 howhowever, your inputs are zonotopes,
minkowski_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_differenceI 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)
so i'm not surprised that
minkowski_difference is fast
Thanks for your help guys! :D
Yes, I followed (but then my supervisor interrupted me)
For my problem, I most likely need to work with
But enabling
Yes, I followed (but then my supervisor interrupted me)
For my problem, I most likely need to work with
HPolytopes so even though the Zonotopes option sounds really interesting, I cannot use it for my current issue.But enabling
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.
they tend to do that :)
yes, it is common that you can write a much more efficient algorithm if you know the type of set you are dealing with
and that's also why preserving more concrete types is beneficial
for instance in your first loop iteration you could work with zonotopes (assuming we have the efficient
minkowski_difference) until the intersection "for free"
but then in the second iteration you will have an
HPolytope and have to use the slower methods
but that happens automatically
i can have a look at JuliaReach/LazySets.jl#1500 (the linear map) in the next days, but if you are eager, you can just add this option yourself and see if it helps (here)
this has a nasty tail, so you have to pass the option through several helper functions :)
basically make this line optional