Skip to content
This repository has been archived by the owner on Dec 7, 2022. It is now read-only.

Population management #55

Closed
2 tasks done
N-Wouda opened this issue Aug 16, 2022 · 5 comments
Closed
2 tasks done

Population management #55

N-Wouda opened this issue Aug 16, 2022 · 5 comments
Assignees
Labels
enhancement New feature or request research Research related discussions

Comments

@N-Wouda
Copy link
Owner

N-Wouda commented Aug 16, 2022

Added by Leon:

  • Never remove the best feasible solution from the population
  • Re-create the "sandwich" between infeasible, best and feasible solutions.
@N-Wouda N-Wouda added enhancement New feature or request research Research related discussions labels Aug 16, 2022
@N-Wouda
Copy link
Owner Author

N-Wouda commented Aug 16, 2022

Originally posted by @N-Wouda in https://github.com/N-Wouda/Euro-NeurIPS-2022/discussions/8#discussioncomment-3405171:

  • How to prune/remove individuals during the survivor selection phase?
  • Should we reintroduce separate feasible/infeasible (sub)populations? See also Individual is possibly added twice in educate #26.
  • How do we compare the fitness/quality of an individual?

@N-Wouda
Copy link
Owner Author

N-Wouda commented Aug 16, 2022

@leonlan

Re-create the "sandwich" between infeasible, best and feasible solutions.

Do you have a picture of this? I'm not sure what this means, but I'd like to know more.

@leonlan
Copy link
Collaborator

leonlan commented Aug 17, 2022

@leonlan

Do you have a picture of this? I'm not sure what this means, but I'd like to know more.

Here's an example from the baseline, look at the "Feas" and "Inf" columns in the table below. The first number denotes the number of individuals in the corresponding subpopulation. The second number is the best individual w.r.t. cost (not sure if including penalties in the infeasible pop, but likely?). The third number is the average cost of the individuals in the subpopulation.

The sandwich that I was referring to is that, in general, it is desirable to have avg feas => best >= avg infeas. My feeling says that this way, the current best solution can escape from the local optima from both crossing with slightly worse feasible and slightly better infeasible individuals.

It   8000    718 | T(s) 49.73 | Feas 45 78202.00 78346.36 | Inf 62 78066.65 78195.24 | Div 0.20 0.18 | Feas 0.30 0.04 | Pen 25.95 0.88
It   8500   1218 | T(s) 52.22 | Feas 30 78202.00 78310.40 | Inf 43 78048.40 78143.64 | Div 0.21 0.17 | Feas 0.25 0.23 | Pen 25.95 0.91
It   9000   1718 | T(s) 54.55 | Feas 53 78202.00 78266.64 | Inf 64 77999.16 78104.90 | Div 0.16 0.16 | Feas 0.27 0.39 | Pen 26.47 0.81
It   9500     87 | T(s) 57.12 | Feas 45 78165.00 78311.52 | Inf 50 77994.11 78086.91 | Div 0.19 0.15 | Feas 0.17 0.02 | Pen 22.50 0.84
It  10000    258 | T(s) 59.64 | Feas 52 78148.00 78246.72 | Inf 41 78004.80 78082.43 | Div 0.16 0.15 | Feas 0.17 0.04 | Pen 27.54 0.87

This behavior is not yet in our current algorithm. See the figure below. Instead, the avg feas/infeas dances around the current best. Especially for infeasible solutions, I think this is undesirable behavior. If infeasible solutions have worse cost than the current best, then any crossover feels wasteful.

I'm now trying to recreate the "sandwiching" behavior on another branch with the things I mentioned above in this issue. E.g., not removing best feasible, but I'm trying to also not removing best infeasible. This is actually almost like having two subpopulations, but the only difference is that our survival mechanism allows for comparison between infeas/feas solutions, which was always separated in the original HGS implementation. It look like I can reproduce the sandwich (see fig) but there's some other drawbacks (having bad diversity and it looks like the infeasible population shows cyclic behavior/can't escape the "population local optima").

@N-Wouda
Copy link
Owner Author

N-Wouda commented Aug 17, 2022

Going back to two separate lists for feas/infeas might be a good way to recreate this, I think. That way, removal/insertion are done separately as well, which is I think what drove this behaviour.

@leonlan
Copy link
Collaborator

leonlan commented Aug 18, 2022

Yea I think we have to move back to separate lists. I'll make an attempt tomorrow

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request research Research related discussions
Projects
None yet
Development

No branches or pull requests

3 participants