Disjunction interface should be simpler

[MagicMuscleMan]

I might be missing something, but why is the interface for disjunctions so complicated? Ideally, the user just enters the disjunction and DisjunctiveProgramming.jl does the reformulation in terms of binary or logical variables.

What the user (ok, I :-)) actually wants is to just enter something like

    for i in 1:P, j in 1:i-1
        @constraint(model, x[i] + width[i] <= x[j] || x[j] + width[j] <= x[i] || y[i] + height[i] <= y[j] || y[j] + height[j] <= y[i])
    end

or maybe something like

    for i in 1:P, j in 1:i-1
        @disjunction(model, [
            x[i] + width[i] <= x[j],
            x[j] + width[j] <= x[i],
            y[i] + height[i] <= y[j],
            y[j] + height[j] <= y[i]])
    end

That some Y is used intermediately for the solver is a detail which is not necessary to formulate the problem as I see it. Such a syntax seems far more readable than what is currently supported (I think. Maybe I am learning something here).

[pulsipher]

The use of logical variables is essential in many GDP applications where disjunctions and logical constraints are defined in tandem: see https://link.springer.com/chapter/10.1007/978-1-4614-1927-3_4. GDP can be a little more verbose sometimes, but it provides a nice way to systematically formulate logical formulations once you get the hang of it. We had considered having @disjunction define all the constraints and logical variables in one shot, but it led to a much more complicated macro, making it much more likely for the user to use incorrect syntax and get a nonsensical error message.

[MagicMuscleMan]

Thanks for the explanations. I understood that for problems where both constraints an logical variables need to be defined, this is probably already the simplest way to do it.

I might be having a special case here, but wouldn't it still make sense to provide an alternative interface (via another @disjunction method as proposed above or via a different macro function) to cover the case where the user is only interested in the constraints, but not in logical variables?

[pulsipher]

Can you provide a concrete example where the standard GDP approach is too verbose and cannot be modelled with indicator constraints (https://jump.dev/JuMP.jl/stable/manual/constraints/#Complementarity-constraints) nor Boolean constraints (https://jump.dev/JuMP.jl/stable/manual/constraints/#Boolean-constraints)?

For your above examples, it doesn't seem too bad to write:

@variable(model, Y[i in 1:P, j in 1:i-1, 1:4], Logical)
@constraints(model, begin
    [i in 1:P, j in 1:i-1], x[i] + width[i] <= x[j], Disjunct(Y[i,j,1])
    [i in 1:P, j in 1:i-1], x[j] + width[j] <= x[i], Disjunct(Y[i,j,2])
    [i in 1:P, j in 1:i-1], y[i] + height[i] <= y[j], Disjunct(Y[i,j,3])
    [i in 1:P, j in 1:i-1], y[j] + height[j] <= y[i], Disjunct(Y[i,j,4])
end)
@disjunction(model, [i in 1:P, j in 1:i-1], Y[i, j, :])

which takes 8 lines of code or

for i in 1:P, j in 1:i-1
    @variable(model, Y[1:4], Logical)
    @constraints(model, begin
        x[i] + width[i] <= x[j], Disjunct(Y[1])
        x[j] + width[j] <= x[i], Disjunct(Y[2])
        y[i] + height[i] <= y[j], Disjunct(Y[3])
        y[j] + height[j] <= y[i], Disjunct(Y[4])
    end)
    disjunction(model, Y)
end

which takes 10 lines but is less redundant and is very close to the syntax you suggested. To have @disjunction process all the constraints directly would be a very involved task since most of the JuMP constraint macro processing is not a public API (i.e., not extendable).

Given that the current approach extends JuMP in the recommended ways, is stable, provides useful error messages, and only seems to minorly increase the verbosity, I am not sure that the suggested change is worthwhile. Also philosophically, GDP formulations rely on the premise of of defining disjuncts of constraints based on logical variables. This is what pyomo.GDP and GAMS disjunctive programming both do as well.

[MagicMuscleMan]

In my case I had a constraint between each pair of variables making it slightly more complicated than your last example, but not unbearably so. In the end I went with indicator constraints because due to the need of defining and handling Y anyway there was not really a benefit of using DisjunctiveProgramming.jl.

My point is not the number of lines or the length of the lines, but the mental load. I can imagine that using this in a scientific context you'll need to write Y in the paper anyway, so you need to mentally process it and so you can also write it down in code, too (I have been past of the scientific community in the past, but in a slightly different field).

However, I approached this problem as a user outside of a scientific context where I just want the optimum placement for my building project. From this perspective, Y really is an implementation detail ("nuisance variable"). I don't even want to know that it exists (besides maybe in the overall number of variables/equations/constraints when explicitly looking at these). I only want to list my constraints as close to the practical problem as possible, get the solution and be done with it.

So I think the question of whether this issue is worth pursuing is a matter of target audience. If mainly the people from the optimization community are targeted, the proposed change does not seem to be worth the effort. If the practitioners should (also) be the target, this change might be worth it to make it as simple as possible for them.

That being said, I understood that the change would be a lot of work. The JuMP.jl API not being public could probably be changed, but means that it will be even more work.
I won't do the work and I can fully understand that you are not interested in doing the work.

So it's probably best to just close this. We have it documented if anyone is interested in the future.
Thanks for the insights and the interesting discussion!