Type unstability with container generation in JuMP

Specific Domains Optimization (Mathematical)
1

Hi,

julia> model = Model(Gurobi.Optimizer)

julia> @variable(model, a[x in 1:10; x < 5], Bin)
JuMP.Containers.SparseAxisArray{VariableRef, 1, Tuple{Int64}} with 4 entries:

julia> @variable(model, b[x in 1:10; x > 15], Bin)
JuMP.Containers.SparseAxisArray{Any, 1, Tuple{Any}} with 0 entries

Here, I would expect the second example to return a JuMP.Containers.SparseAxisArray{VariableRef, 1, Tuple{Int64}}
The current behavior can cause type unstability if we don’t check the emptiness of the resulting container beforehand.

Is it the expected behaviour and are we expected to do the emptiness check by ourselves ?

2

If the container is empty, it cannot know the element type.

Does the Any actually matter? You can’t end up using b, so it shouldn’t impact anything…

3

I guess the type can be known by using eltype(1:10). I’m not aware of a construction allowed by JuMP where the type could not be inferred.

I wrap my model in a structure with the variables and some other objects. Then I add constraints. My code for generating the constraints does generally not need a special case when a set of variables is empty. The type of the variables is required for type signature in the structure, to ensure type inference all the way down.

.

4

Can’t you check if this will be the case and then explicitly create an empty and correctly typed JuMP.Containers.SparseAxisArray to use in its place?

5

Yes, this is a possible workaround, but from a design perspective, I think the proposed behaviour is a better one.