[GeneralDichotomy] handle no solution case

[smbct]

In reply to #203:

I replaced the initial scalarization by w=(1, .., 1). The missing solution case can be detected at the beginning by solving a simple sum of the objectives:

• if one of the objective is unbounded, any sum with non zero coefficients should be also unbounded
• if the problem is infeasible, any linear scalarization should be infeasible as well

Then, if any sub-problem is infeasible, this must be due to numerical issues, hence returning MOI.NUMERICAL_ERROR in the main loop.

(PS sorry for the duplicate PR)

[codecov]

Codecov Report

❌ Patch coverage is 90.47619% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 99.51%. Comparing base (b71397a) to head (8990d1f).

Files with missing lines	Patch %	Lines
ext/Polyhedra/GeneralDichotomy.jl	90.47%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #207      +/-   ##
==========================================
- Coverage   99.64%   99.51%   -0.14%     
==========================================
  Files          15       15              
  Lines        1421     1434      +13     
==========================================
+ Hits         1416     1427      +11     
- Misses          5        7       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[odow]

if one of the objective is unbounded, any sum with non zero coefficients should be also unbounded

counter example: min [x, -x] with x free. The (0.5, 0.5) vector has a bounded objective.

[odow]

Suggested change

	w = ones(Float64, n_obj)
	w = fill(1 / n_obj, n_obj)

Does it matter?

[smbct]

At this stage, this weight is not kept to be part of the "decomposition", so its range does not matter here. (1,..,1) is unlikely to ba an "extreme weight" since extreme weights verify w dot y^1 = w dot y^2 = ... (usually there is equality for d solutions if there are d objectives). This is really the same as the dichotomy method.

In the main loop, all extreme weights are obtained from the Polyhedron vertices enumerations, so they verify both the range and the equality. (and initial weights e.g. (1,0,..,0) verify this as well when there is one recorded solution)

[odow]

I think we need to first check the ideal point, and then go for it. I'd also suggest that if we run into issues we just prune the weight and keep exploring other weights. There might be more solutions that we can find, even if one solve fails.

[odow]

This is what we do in KS:

MultiObjectiveAlgorithms.jl/src/algorithms/KirlikSayin.jl

Lines 176 to 183 in b71397a

	if !_is_scalar_status_optimal(model)
	_log_subproblem_solve(model, "subproblem not optimal")
	# If this fails, it likely means that the solver experienced a
	# numerical error with this box. Just skip it.
	MOI.delete.(model, ε_constraints)
	MOI.delete(model, zₖ_constraint)
	_remove_rectangle(L, _Rectangle(_project(yI, k), uᵢ))
	continue

[smbct]

counter example: min [x, -x] with x free. The (0.5, 0.5) vector has a bounded objective.

Correct. I had not considered cancelling objectives.

I think we need to first check the ideal point, and then go for it.

Alright, I will then make changes to process all initial weights before starting the main loop.

This is what we do in KS:

In the dichotomy, it is fine to process a solution (to compute weights) even if it is not optimal. The search is stopped if the weighted sum comparison fails but there should be no issue in the weight update. We can hence simply add the log message.

[odow]

I think the place to put this logging is in

MultiObjectiveAlgorithms.jl/src/algorithms/GeneralDichotomy.jl

Lines 62 to 65 in b71397a

	status = MOI.get(model.inner, MOI.TerminationStatus())
	if !_is_scalar_status_optimal(status)
	return status, nothing
	end

[odow]

Remove this logging in favor of one in _solve_weighted_sum