Skip to content

fix(database): choose island migrants before moving any - #524

Open
flyingdoubleG wants to merge 1 commit into
algorithmicsuperintelligence:mainfrom
flyingdoubleG:fix/migration-snapshot
Open

flyingdoubleG wants to merge 1 commit into
algorithmicsuperintelligence:mainfrom
flyingdoubleG:fix/migration-snapshot

Conversation

@flyingdoubleG

Copy link
Copy Markdown

Problem

ProgramDatabase.migrate_programs (default ring migration) picks each island's migrants while it is already moving the previous islands' migrants:

  1. Island i's best programs are copied into island i+1 (and i-1) before island i+1 is processed.
  2. When island i+1 is processed, the fresh copies (metadata["migrant"] = True) compete for its top max(1, int(n * migration_rate)) slots. _migrate_one skips migrants, so those slots are wasted.
  3. Worse, the incoming copies can displace island i+1's own programs from their MAP-Elites cells before they get a chance to migrate.

The result depends on island order, and good programs on later islands may never leave their island. test_migration_ring_topology already notes this as "a known limitation of the current implementation that processes islands sequentially while modifying them, causing interference between migration rounds."

Repro: 3 islands, migration_rate=0.1, one program per island with scores 0.9 / 0.5 / 0.3 in distinct cells, then one migrate_programs() call:

main:     island 0: ['a']   island 1: ['a', 'b']   island 2: ['a', 'c']
this PR:  island 0: ['a', 'b', 'c']   island 1: ['a', 'b', 'c']   island 2: ['a', 'b', 'c']

On main only the top program spreads; b and c never migrate.

Fix

  • Plan all moves from the pre-migration population first, then apply them.
  • Exclude existing migrant copies from migrant selection, since _migrate_one would skip them anyway.

The pluggable population_strategy.migrate path is unchanged.

Tests

New test_every_island_migrates_its_own_best covers the scenario above. It fails on main and passes with this change. tests/test_island_migration.py, test_migration_no_duplicates.py, test_island_isolation.py, test_database.py and test_population_strategy.py all pass: 66 tests, CPU.

🤖 Generated with Claude Code

migrate_programs picked each island's migrants while it was already
moving the previous islands' migrants. Island i's best copies land in
island i+1 before i+1 is processed, so i+1's top migration slots went to
those fresh copies (which _migrate_one skips, since migrants never
migrate again) and the copies could displace i+1's own programs from
their cells first. In a 3-island ring with bests 0.9 / 0.5 / 0.3 in
distinct cells, only the 0.9 program ever spread; the others never left
their island. The existing ring test already noted this as a "known
limitation".

Plan all moves from the pre-migration population, and do not let
migrant copies take migration slots.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

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.

2 participants