Skip to content

fix(como_cmaes): default reference point from the known nadir, and report kernels when none dominates it - #812

Open
sean-from-japan wants to merge 2 commits into
anyoptimization:mainfrom
sean-from-japan:fix/como-cmaes-nadir-reference
Open

sean-from-japan wants to merge 2 commits into
anyoptimization:mainfrom
sean-from-japan:fix/como-cmaes-nadir-reference

Conversation

@sean-from-japan

Copy link
Copy Markdown

Fixes #811

Changes

  • When reference_point is None and the problem knows its Pareto front, the reference point is now nadir + 0.1 * (nadir - ideal). COMO-CMA-ES approximates the optimal p-distribution of the hypervolume, so its reference point should be fixed just beyond the nadir, as in the authors' bbob-biobj benchmark. If the front is unknown, or loading it raises OSError (for example a failed download), the current far fallback is kept.
  • If no kernel dominates the reference point, _advance now reports the kernels' incumbents. Before, self.pop was never updated in that case and the result was the initial random sample. This showed up on ZDT4 once the reference point was near the nadir.
  • Updated the reference_point docstring.
  • Added four tests.

Results

Default arguments, 300 generations, seeds 1–3:

Problem main: front size main: IGD this PR: front size this PR: IGD
ZDT1 8–10 0.099–0.107 32 0.012
ZDT2 2–3 0.351 29–32 0.017
ZDT3 10–11 0.12–0.24 14–21 0.030–0.045
ZDT4 5–9 12–20 4–8 2.2–3.6
ZDT6 5–11 0.29–0.30 15–20 0.067–0.109

Problems without a known Pareto front, such as bbob-biobj through cocoex, take the unchanged fallback, so the bbob-biobj behaviour measured in 527ec67 does not change.

Testing

  • pytest tests/algorithms/test_como_cmaes.py tests/algorithms/test_mocmaes.py: 11 passed.
  • On main, test_como_cmaes_default_reference_point_uses_known_nadir and test_como_cmaes_default_does_not_stall_on_zdt1 fail. Without the second change, test_como_cmaes_reports_kernels_when_none_dominates_reference_point fails.
  • Merges cleanly with fix(como_cmaes): reject constrained problems instead of ignoring constraints #810, and the combined test file passes.
  • No new ruff check or ruff format --check findings.

Note

problem.pareto_front() downloads the front for some problems, and no other pymoo algorithm reads the known front during a run. If you prefer to avoid that, I can reduce this PR to the reporting fix and the documentation.

COMO-CMA-ES approximates the optimal p-distribution of the hypervolume, so
its reference point should be fixed just beyond the nadir. The far default
[R, R] gives dominated kernels on a bounded objective a zero UHVI distance,
and most kernels stall on f1 = 0 on ZDT1-3 (anyoptimization#811).

When the problem knows its Pareto front, use nadir + 0.1 * (nadir - ideal).
Otherwise keep the far fallback, and document it.
If no kernel dominates the reference point, pareto_front_cut is empty and the
population was never updated, so the result was the initial random sample.
On ZDT4 with reference point [1.1, 1.1] the kernels reach f2 of about 4 while
the returned front still had f2 of about 100. Fall back to the kernels'
incumbents in that case.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] COMOCMAES: most kernels stall on the f1 = 0 boundary of ZDT1–3 when the reference point is far away (including the default)

1 participant