awkward behavior of macro @variable

[IssamT]

FIRST_INPUT

workspace()

using JuMP
using Cbc
using Graphs

petersen = simple_petersen_graph()

function max_independent_set(g::SimpleGraph)

    m = Model(solver=CbcSolver())      
    @variable(m, b[v in vertices(g)], Bin)   
    @constraint(m , nonadjacency[e in edges(g)], b[source(e)] + b[target(e)] <= 1)
    @objective(m, Max, sum{b[v] , v in vertices(g)})

    solve(m)

    @show typeof(1:10)
    @show typeof(vertices(g))    
    @show typeof(b)         
end

max_independent_set(petersen)

FIRST_OUTPUT:

typeof(1:10) = UnitRange{Int32}
typeof(vertices(g)) = UnitRange{Int32}
typeof(b) = JuMP.JuMPArray{JuMP.Variable,1,Tuple{UnitRange{Int32}}}

MODIFYING_INPUT

Instead of
@variable(m, b[v in vertices(g)], Bin)
I write
@variable(m, b[v in 1:10], Bin)

SECOND_OUTPUT

typeof(1:10) = UnitRange{Int32}
typeof(vertices(g)) = UnitRange{Int32}
typeof(b) = Array{JuMP.Variable,1}

Notice that 1:10 and vertices(g) are exactly the same (and have the same type) in my case, except on the symbolic level which, in my opinion, is causing the issue here.

I think that for the current version, it would be worth mentioning somewhere in the doc that if you use, for indices, a unit range as a "literal" the variables will be stored in an array but if you use a unit range not as a "literal" the variables will be stored in a dictionary; since this can have an impact on the performance, especially for callbacks...

[mlubin]

This is a dup of the longstanding issue #346. Shouldn't be too hard to implement at this point.