completing variable indices

[juan-pablo-vielma]

The following code fails in the last command.

---

m = Model()
@defvar(m,x[1,1:2])
@addConstraint(m,x[1,1]+x[1,2]<=1)
@defvar(m,x[1,0]>=0)
@addConstraint(m,x[1,1]+x[1,2]+x[1,0]<=1)

ERROR: key not found: 1
in getindex at dict.jl:515
in getindex at no file

---

This code could be useful when dealing with socp constraints. There is an easy fix bellow, but adding new indices as above could be useful (if it is feasible).

---

m = Model()
@defvar(m,x[1,i=0:2]>= ( i == 0 ? 0 : -Inf))
@addConstraint(m,x[1,1]+x[1,2]<=1)
@addConstraint(m,x[1,1]+x[1,2]+x[1,0]<=1)

---

[mlubin]

That's not really feasible with the current way that variables are handled. The easiest workaround is to use a different name for the 0-index variable.

[joehuchette]

You can also change the lower bounds after definition:

m = Model()
@defVar(m,x[1,0:2]>= 0)
setLower(x[1,0], -Inf)
@addConstraint(m,x[1,1]+x[1,2]<=1)
@addConstraint(m,x[1,1]+x[1,2]+x[1,0]<=1)

[mlubin]

That also works but is less pretty. At some point we might allow you to say that a given vector of variables is constrained to be in the Lorentz cone.

[joehuchette]

Definitely, once we get block structures we can do all kinds of cool things

[joehuchette]

This is now possible with, e.g.

julia> @defVar(m, x[1,1:2])
x[i,j], for all i in {1}, j in {1..2} free

julia> x[1,0] = @defVar(m, foo >= 0)
foo

julia> x[1,0]
foo

We could potentially make it work so that you could do

@defVar(m, x[1,1:2])
@defVar(m, x[1,0] >= 0)

and have things work as expected, but it's not clear that that's the best behavior (though many people seem to expect this kind of behavior).

[mlubin]

This seems to be a pretty common point of confusion with users, but I don't think we can address it cleanly yet. Let's not publicize the fact that you can add variables to JuMPContainers.

[joehuchette]

Yep, I intentionally left it off the docs. We can only add variables to JuMPDicts, also, which makes things even more confused. Staged functions will also help make the code to potentially do this a bit cleaner.

[mlubin]

Coming back to this, I think there's no way that we can support the semantics for adding variables to JuMPContainers.
For example, if we had:

S = [:a, :b, :c]
@defVar(m, x[S])
@addConstraint(m, sum{x[s], s in S} <= 1)
@addVar(m, x[:d]) # or something like this

then a user coming from AMPL and similar AMLs could expect that :d would be added to S and then constraint would be updated correspondingly as well. Since JuMP doesn't and won't do this, I think that providing a potentially misleading syntax is worse than the current state where users need to keep their own lists of variables when adding them dynamically.

[joehuchette]

OTOH, the name JuMPDict is a bit confusing if you can't push elements to it.

[joehuchette]

That being said, the only really compelling case I've seen for appending elements to a JuMPDict is @juan-pablo-vielma example with the Lorentz cone. In the case of column generation, I think using Julia containers instead is probably a better idea. We could bypass this by having build-in cone definitions (@defLorentz(x[10])? @defSDPVar?) to do this in a cleaner way.

[mlubin]

Is this resolved? Should we add support for @defVar(m, x[1:4], SOC)? Doesn't seem to be in high demand.

[joehuchette]

Should be like 10 lines of code, can add once someone asks.