Feature request: reuse a variable name in `@variable` on non-overlapping indices

[remi-garcia]

It would be nice if the following code works

using JuMP
model = JuMP.Model()
@variable(model, -5 <= x[0:5] <= 5, Int)
@variable(model, -5 <= x[6:12] <= 5, Int)

or

for i in -7:7
    @variable(model, x[i], lower_bound=foo(i))
end

We could reuse a variable name if the indices on which it is defined don't overlap.

This has been discussed on discourse. Thanks to @odow I use this solution:

using JuMP
model = Model()
n = 10
x = Dict{Int, VariableRef}(
    i => @variable(model, base_name = "x[$(i)]")
    for i = 0:n
)

n += 1
x[n] = @variable(model, base_name = "x[$n]")
@constraint(model, x[n] <= foo(n))

and when x is needed in another function it can be assigned like this:

n = 0
while variable_by_name(model, "x[$n]") !== nothing
    n += 1
end
n -= 1
x = Dict{Int, VariableRef}(
    i => variable_by_name(model, "x[$i]")
    for i in 0:n
)

This works for me, yet a better way (first block of code) to achieve this would be great.

[odow]

I'm not in favor of this. It seems like it would lead to too many typos in user-code, and lead to too many edge cases.

For example, what should happen here?

@variable(model, x[1:2])  # x is Vector{VariableRef}
@variable(model, x[-1:0])  # Now x needs to be converted into a DenseAxisArray?

We should probably add more examples to:
https://www.juliaopt.org/JuMP.jl/stable/variables/#User-defined-containers-1
and highlight its importance in other parts of the documentation, e.g., at the start of the variable container section:
https://www.juliaopt.org/JuMP.jl/stable/variables/#Variable-containers-1

p.s.

You can go

model[:x] = x = Dict{Int, VariableRef}(
    i => @variable(model, base_name = "x[$(i)]")
    for i = 0:n
)

to facilitate model[:x] in another function.

[henriquebecker91]

Such feature would be useful to me too. I have an array of constraints representing plates of a guillotine 2D knapsack problem, and the constraint for the original plate (from which all others are cut from) is different from the rest of the constraints, so I end up with a single variable (that would be the first index) and an array 2..n, other methods expect a vector of constraint references to compute duals and such over this set. If it is not a problem to add you own collections to model, then the workaround solves my problems. However seems to me that the automatic promotion needed for this feature to work is similar to what is already done by @variable when it has to choose a container for the variable collection defined, no?

I think it would be interesting to have this workaround in the docs, together with the first section you pointed out. If you agree I can open a PR.

[odow]

Yes, I think a PR to the docs is the best way forward.

I don't think we're going to modify how containers are constructed.

Instead, we encourage users to build their own containers. They don't need to restrict themselves to the three in-built ones.