Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

317 crowding distance calc needs to handle single individual pops #318

Conversation

markcoletti
Copy link
Collaborator

Added more robust handling of edge case whereby crowd distance calculations should have distances of 0 for individuals in a rank by themselves. (I.e., they have no neighbors, so no distance.)

This resolves an issue found by Robert Patton while he was using NSGA-II.

markcoletti and others added 6 commits October 10, 2023 14:08
…population of a single individual, in which case we should assign a distance of 'inf' to indicate it has no neighbors. We also return the population that was given since the sorting mechanism may yield empty lists, which is what we were previously returning.
@markcoletti markcoletti added the bug Something isn't working label Jan 31, 2024
@markcoletti markcoletti self-assigned this Jan 31, 2024
@markcoletti markcoletti linked an issue Jan 31, 2024 that may be closed by this pull request
@lukepmccombs
Copy link
Contributor

lukepmccombs commented Jan 31, 2024

I thought individuals in ranks of size 1 would already have a distance of 0, since all objectives would be degenerate (range of 0) and I changed it to skip those objectives for setting infs. I just tested it, though, and numpy would give a nan value for an objective range if the rank has solely nan or +/- inf fitnesses in that objective, which is seen as non-degenerate since its non-zero. This is probably undesirable, even if those fitnesses usually denote some other issue, since crowding distances would be wrong. The fix is simple so I'll make a PR to this branch for it, but do you know if that was the case when Robert encountered the bug?

Also, I see where the bug was with returning sorted_pop, but I'm pretty certain we don't depend on that return value being sorted along an objective. Your fix looks good to me.

@SigmaX
Copy link
Collaborator

SigmaX commented Feb 1, 2024

Can we merge this into develop instead of master?

Also could use unit tests (sorry for repeating this in two separate places).

@markcoletti markcoletti changed the base branch from master to develop February 1, 2024 15:58
markcoletti and others added 6 commits February 1, 2024 11:19
…needs-to-handle-single-individual-pops

Also skip nan range objectives, which are degenerate if fitnesses are inf
…-to-handle-single-individual-pops' into 317-crowding-distance-calc-needs-to-handle-single-individual-pops
… a single threaded worker. Hypothesis was that there were too many workers spun up by default that consumed too many resources. Besides, we only need a single worker given the nature of the distributed unit tests.
…-to-handle-single-individual-pops' into 317-crowding-distance-calc-needs-to-handle-single-individual-pops
@markcoletti
Copy link
Collaborator Author

The Windows python 3.9 check is failing for one of the distributed unit tests. It doesn't fail anywhere else, so there's something about that magic combo that's causing problems. At this point I don't have the bandwidth to track this down; if we have someone on Windows that encounters this problem, then we can take a deeper dive. However, I don't think we have any users that match that criteria.

@markcoletti markcoletti merged commit 2145ab2 into develop Feb 1, 2024
1 of 9 checks passed
@markcoletti markcoletti deleted the 317-crowding-distance-calc-needs-to-handle-single-individual-pops branch February 1, 2024 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

crowding distance calc needs to handle single individual pops
3 participants