Make line search for polyhedral computations optional

[schillic]

julia> H = HalfSpace([-1.0, -1.0], -3.0);
julia> P = VPolygon([[1.0, 1.0], [3.0, 1.0], [2.0, 3.0]]);

This works:

julia> plot(Intersection(H, P))
julia> plot!(H)

This does not work:

julia> plot(H)
julia> plot!(Intersection(H, P))

AssertionError: package 'Optim' not loaded (it is required for executing `ρ` (algorithm line_search))

The problem is that plot! calls box_approximation and thus ρ:

julia> ρ([1.0, 0.0], Intersection(H, P))

AssertionError: package 'Optim' not loaded (it is required for executing `ρ` (algorithm line_search))

The result can alternatively be computed concretely in this case. A suggestion would be to add an algorithm "hrep" that converts to H-rep. This should be the default for polyhedra when Optim is not loaded. We can optionally print a warning that loading Optim may be faster the first time this happens.

[mforets]

Isn't this a problem with dispatch? Since ρ([1.0, 0.0], Intersection(H, P)) <= min(ρ([1.0, 0.0], H), ρ([1.0, 0.0], P)) produces an approximation that doesn't require other packages. Perhaps the "fix" is to change the default to be <= and use Optim on demand. What you suggest is better but only applies in 2D.

[schillic]

Isn't this a problem with dispatch?

Why?

Perhaps the "fix" is to change the default to be <= and use Optim on demand.

Sounds good. Although I start wondering whether we should use a precise default because when you plot the set you expect it to be precise, and the <= approximation can get arbitarily bad. Should we maybe print a warning when the <= algorithm was chosen as default (because Optim was not loaded)? Otherwise it may look like a bug when you do not get the "correct" set.

What you suggest is better but only applies in 2D.

Hm, if Polyhedra is loaded, we can also do this in higher dimensions. But it probably gets too expensive.