In problem modification, typeof(inconstraints) = JuMPDict{ConstraintRef{T<:JuMPConstraint},1} is not accepted

[Shuvomoy]

It seems that for problem modification, type of inconstraints references has to be JuMPArray{ConstraintRef{T<:JuMPConstraint}}. If the type of the constraint references is JuMPDict{ConstraintRef{T<:JuMPConstraint},1}, then just giving the name of the JuMPDict (e.g., inconstraints = nameJuMPDict) results in the following error:

`Variable` has no method matching Variable
#(::Model, ::Int64, ::Float64, ::Symbol, ::Float64, ::JuMPDict{ConstraintRef{T<:JuMPConstraint},1}, ::Array{Float64,1}, ::ASCIIString, ::Float64)

To use JuMPDict we still have to write:
inconstraints = ConstraintRef{LinearConstraint}[nameJuMPDict[i] for i in M]

Please see the following code for a test example. Here, from an end-user point of view, there is not much of a difference between the JuMPArray and JuMPDict.

# Standard form LP:
#                                   minimize    cᵀx 
#                                   subject to  Ax = b
#                                                 x>=0
#                         A ∈ Rᵐ*ⁿ , b ∈ Rᵐ , c,x ∈ Rⁿ

# Test Data 
# ---------
c = [1; 3; 5; 2] 

A= [
     1 1 9 5;
     3 5 0 8;
     2 0 6 13
    ]

b = [7; 3; 5] 

m, n = size (A) 

# JuMP model
# ----------

using JuMP  

using GLPKMathProgInterface  

sfLpModel = Model(solver=GLPKSolverLP())

@defVar(sfLpModel, x[1:n] >= 0) 

# ***********************************************************************

@defConstrRef consRefLp1[1:m] # If we replace this with the follwoing two lines:
# mathcalM = [1:m] 
# @defConstrRef consRefLp1[mathcalM] # type of consRefLp1 is JuMPDict{ConstraintRef{T<:JuMPConstraint},1}
# then problem modification will give following error:
#`Variable` has no method matching Variable
#(::Model, ::Int64, ::Float64, ::Symbol, ::Float64, ::JuMPDict{ConstraintRef{T<:JuMPConstraint},1}, ::Array{Float64,1}, ::ASCIIString, ::Float64)

println("Type of the constraint references are: ", typeof(consRefLp1))
# *************************************************************************

for i=1:m # for all rows do the following
    consRefLp1[i] = @addConstraint(sfLpModel, sum{A[i,j]*x[j] , j=1:n} == b[i]) 
end 

@setObjective(sfLpModel, Min, sum{c[j]*x[j], j=1:n})

println("The optimization problem to be solved is:")

print(sfLpModel)

status1 = solve(sfLpModel) 

println("Objective value of the original problem : ", getObjectiveValue(sfLpModel))

println("Optimal solution of original problem is x = \n", getValue(x)) 

#Problem modification
#--------------------

@defVar(sfLpModel, xNew >= 0, objective = - 1.0, inconstraints = consRefLp1, coefficients = [1; 2; 3.0])

println("The modified optimization problem is:")
print(sfLpModel)

status2 = solve(sfLpModel)  

println("Objective value of modified problem: ", getObjectiveValue(sfLpModel)) 

println("Optimal solution of modified problem is x = \n", getValue(x), "[5] = ", getValue(xNew))```

[mlubin]

We recommend declaring index sets which are ranges explicitly like @defVar(m, x[1:N]) instead of

S = 1:N
@defVar(m, x[S])

because JuMP performs an analysis at compile time based on syntax, and it's impossible to know at that time that S is an ordered range. There could be an opportunity to use staged functions here once we move to the explicit JuMPArray type (#192). In summary, I recognize that this is an issue but there are some technical hurdles that need to be overcome before we can develop a good solution.

[Shuvomoy]

Thanks for the information!

I think the issue is not that important, because this can be easily avoided if your suggestion is followed.

[mlubin]

Closing in favor of #346