Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions src/algorithms/TambyVanderpooten.jl
Original file line number Diff line number Diff line change
Expand Up @@ -187,12 +187,12 @@ function minimize_multiobjective!(
bounds_to_remove = Vector{Float64}[]
for u_i in keys(U_N)
for k in 1:n
if u_i[k] == yI[k]
if isapprox(u_i[k], yI[k]; atol = 1e-6)
push!(bounds_to_remove, u_i)
else
for (u_j, y_j) in V[k]
if all(_project(u_i, k) .<= _project(u_j, k)) &&
(y_j[k] == u_i[k])
isapprox(y_j[k], u_i[k]; atol = 1e-6)
push!(bounds_to_remove, u_i)
end
end
Expand All @@ -205,6 +205,6 @@ function minimize_multiobjective!(
end
end
end
solutions = [SolutionPoint(X, Y) for (Y, X) in solutions]
return status, solutions
solutions_vec = [SolutionPoint(X, Y) for (Y, X) in solutions]
return status, filter_nondominated(MOI.MIN_SENSE, solutions_vec)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? In #133, we round the solutions to be integers but I think they are actually different points. Just slightly different due to floating points. Also, solutions is a Dict so the keys should be unique.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The list of solutions prior to filtering includes stuff like this:

 [1277.0, 991.0, 1077.0]
 [1277.0, 991.0000000000001, 1077.0]

Maybe we need to change if Y ∉ U_N[u][k] to be approximate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's what I was referring to. We could change it but that would be slower, right? We could allow this and change the test to check for rounded nondominated set. The tradeoff is to allow these approximately equal but ultimately distinct points and pay the price to solve extra scalarizations or check for approximately equality and avoid extra scalarazations. The cost of solving more scalarazations is not perhaps significant for knapsack but it could be for some other problem.

end
24 changes: 24 additions & 0 deletions test/problems.jl
Original file line number Diff line number Diff line change
Expand Up @@ -472,4 +472,28 @@ function test_issue_122(model)
return
end

function test_issue_133(model)
#!format: off
p = Float64[
33 90 96 75 1 69 100 50 63 61 59 95 58 10 77 30 86 89 82 51 38 33 73 54 91 89 95 82 48 67
55 36 80 58 20 96 75 57 24 68 37 58 8 85 27 25 71 53 47 72 57 64 1 8 12 68 3 80 20 90
22 40 50 73 44 65 12 26 13 77 14 68 71 35 54 98 45 95 98 19 18 38 14 51 37 48 35 97 95 36
]
w = Float64[
22, 13, 10, 25, 4, 15, 17, 15, 15, 28, 14, 13, 2, 23, 6, 22, 18, 6, 23,
21, 7, 7, 14, 4, 3, 27, 10, 5, 9, 10
]
#!format: on
x = MOI.add_variables(model, length(w))
MOI.add_constraint.(model, x, MOI.ZeroOne())
MOI.set(model, MOI.ObjectiveSense(), MOI.MAX_SENSE)
f = MOI.Utilities.vectorize(p * x)
MOI.set(model, MOI.ObjectiveFunction{typeof(f)}(), f)
MOI.add_constraint(model, w' * x, MOI.LessThan(204.0))
MOI.optimize!(model)
@test MOI.get(model, MOI.TerminationStatus()) == MOI.OPTIMAL
@test MOI.get(model, MOI.ResultCount()) == 95
return
end

end # module Problems
Loading