GeneralDichotomy implementation proposition

[smbct]

I have implemented our algorithm from the following preprint, that computes supported pareto fronts:

Samuel Buchet, Marianne Defresne. Efficient Enumeration of Supported Solutions for General Multi-Objective Optimization Problems. 2026. ⟨hal-05514317⟩

Our reference repository is at https://forge.inrae.fr/opteam/generaldichotomy

The current version is fairly functional but there are few issues to be addressed:

• it depends on Polyhedra. I temporarily moved it as a "strong" dependence but I may try to move the corresponding computation to ext as it is done for Sandwiching
• it has few parameters, especially precision that handles fixed point comparisons on decimal values and scaling for weight range. They are currently directly set from the algorithm instance
• there is a custom verbose parameter that may be replaced by the attribute silent

[codecov]

Codecov Report

❌ Patch coverage is 98.23009% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 99.64%. Comparing base (b93d249) to head (f7b7069).

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #200      +/-   ##
==========================================
+ Coverage   97.76%   99.64%   +1.88%     
==========================================
  Files          12       15       +3     
  Lines        1251     1421     +170     
==========================================
+ Hits         1223     1416     +193     
+ Misses         28        5      -23     

☔ 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]

Nice! I'm super happy to have a contribution!

A few comments to point you in the right direction.

• See the test failure on Julia v1.10
• See also the required format changes.

See also the code coverage: https://app.codecov.io/gh/jump-dev/MultiObjectiveAlgorithms.jl/pull/200?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=checks&utm_campaign=pr+comments&utm_term=jump-dev

We can remove the verbose things once you're happy with the development. But we need to add some more tests to hit all of the code paths. Bits like this aren't being tested:

it depends on Polyhedra. I temporarily moved it as a "strong" dependence but I may try to move the corresponding computation to ext as it is done for Sandwiching

Yes please move to an ext, but if you can't figure out the details, just leave it as is, and once we're happy I can do it.

[smbct]

Thank you for the feedback!

Should I mention I am relatively new to Julia 😁
I have integrated most of your comments. Nice to see that MOA is able to handle maximization problems. In our reference implementation however, we additionally support e.g. [min, max, min] etc..

Before cleaning the blank lines and debug messages, I need to check some of the tests (bensolve vlp example). Also moving Polyhedron calls to ext. is left to do.

[odow]

Should I mention I am relatively new to Julia

Welcome! I might take over from here for a bit and make a few changes.

In our reference implementation however, we additionally support e.g. [min, max, min] etc..

See Section 5.3 of https://arxiv.org/pdf/2507.05501

I need to check some of the tests (bensolve vlp example)

Yes, proper testing is somewhat of an open question: #113

We've found many finicky bugs associated with tolerances etc.

Also moving Polyhedron calls to ext. is left to do.

I can do this. See #201.

[odow]

@smbct what should happen here? It might be that this weight is unbounded, or it might be that there is some numerical issue that causes the solver to fail.

[smbct]

This is a good question. Here is few observations:

• Weights should not be unbounded, except on issues with the polyhedron vertices enumeration. The Weight set is always bounded.
• I see two possible issues : 1) there is no solution or 2) the resulting solution is not optimal
• In 1) the weight is marked as tested so the algorithm won't process it again. The set of solutions (supported front) would be incomplete.
• In 2), weight is considered tested once again. But now the set of solutions contains sub-optimal solutions. There is no problem on updating the weight set with that. However the resulting front is not a true supported front.

In any case, I don't think there would be an issue on the termination criteria. And in the worst case, the time limit would do the job.

However, it should be relevant to handle 2) and to notify the user that the front is incomplete and/or contains suboptimal solutions.

[odow]

Weights should not be unbounded, except on issues with the polyhedron vertices enumeration. The Weight set is always bounded.

I meant that, given the weight vector, the scalarized problem might be unbounded. The way we check this in other algorithms is by first searching for the ideal point by solving each objective in isolation.

[odow]

I've merged this. We can make any tweaks in smaller PRs before tagging a new version 😄

[smbct]

Thank you for cleaning and merging! The final code ends up fitting nicely in MOA, less than 200 lines of code! 💯

There is at least two things to discuss: wnorm and your the concerns when solving status is not optimal.

[odow]

The final code ends up fitting nicely in MOA, less than 200 lines of code!

Yes, I hope you'll see now why we like JuMP, Julia, and MultiObjectiveAlgorithms.jl! It's a great toolbox for experimenting with new algorithms. For a very small investment, you get instant access to a very user-friendly interface.

There is at least two things to discuss: wnorm

Yes, I don't really understand the purpose of wnorm. Why can't it be 1.0?

[odow]

Let's discuss in the separate issues #203 and #204