I’m not positive now.
I tried @dpsanders’s solution on a larger —but still on topic—
problem and found a huge use of resources. Example below.
μ = [0,2,3,1]
ν = [2,2,1,1]
components = 4 # μ |> length
vars = @variables y[1:components,1:components]
constriction_list = Separator[]
for i in 1:components
push!(constriction_list, Separator(vars..., sum(vars[1][i,1:components]) == μ[i]))
end
for i in 1:components
push!(constriction_list, Separator(vars..., sum(vars[1][1:components,i]) == ν[i]))
end
X = IntervalBox(0..(components*components), (components*components)) # domain
for c1 in constriction_list
X = c1(X)[1]
end
ini = ∩(constriction_list[1], constriction_list[2])
for ci in constriction_list[3:end]
ini = ∩(ini, ci)
end
p = pave(ini, X, 1e-2)
unique(integerize.(p.boundary))
So, is this (large memory usage) an issue with the way I extended the solution or indeed IntervalConstraintProgramming
is not apt to this new problem?
ps1. I was unable to use a function for the previous code. I had a problem similar to The applicable method may be too new: running in world age 28047, while current world is 28055.
ps2. In case someone wants to copy-paste code from this post, you need to add to @dpsanders’s code using IntervalArithmetic