- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

- Jan 19 15:59mforets edited #190
- Jan 19 15:55abduld starred JuliaReach/MathematicalSystems.jl
- Jan 18 23:14ueliwechsler synchronize #125
- Jan 18 23:14ueliwechsler synchronize #125
- Jan 18 23:14
ueliwechsler on 76

Apply suggestions from code rev… (compare)

- Jan 18 15:21imbsky starred JuliaReach/MathematicalSystems.jl
- Jan 18 11:02schillic labeled #1916
- Jan 18 11:02schillic labeled #1916
- Jan 18 11:02schillic commented #1916
- Jan 18 11:00schillic edited #1916
- Jan 17 22:44ueliwechsler opened #1916
- Jan 17 17:59schillic edited #190
- Jan 17 17:57
schillic on transmission_line

fix computation of X0 (compare)

- Jan 17 17:57schillic synchronize #190
- Jan 17 17:10schillic edited #190
- Jan 17 17:10schillic synchronize #190
- Jan 17 17:10
schillic on transmission_line

add temporary fix of matrix inv… (compare)

- Jan 17 17:07schillic edited #190
- Jan 17 16:45schillic edited #190

For example, for the

Or does it make totally sense, that the

`minkowski_difference`

I know that I solve #constraint linear programs (therefore, it is linear in the number of constraints) and I was surprised, that the `linear_map`

does take significantly more time than the `minkowski_differnence`

and now, I try to figure out why exactly.Or does it make totally sense, that the

`linear_map`

takes more time?
they are very fast if the sets are zonotopic

since then linear maps are just the action over the generators

yes, to have an option to pass the inverted matrix

if the matrix is invertible then the linear map can be computed *without* passing to the vrep

it is easy, just see how it transforms each constraints

in the general case (the matrix is not invertible) you have to pass to the vertex representation and this can be expensive

`linear_map`

inverts again
there should be an option to pass

`S`

directly
and still

if we pass

`S`

to `linear_map`

there should be an option to pass S directly

maybe our messages crossed

yes, but it is computed only once in his function

it is *needed* to be computed only once in his function, this is what i meant

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,*some* bottleneck :P)

`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 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)

so i'm not surprised that

`minkowski_difference`

is fast