Closed schrum2 closed 1 year ago
Once we have logging of the bin/sub-pop sizes to verify, this issue can be closed. Basically, we need another log, structured like all the other archive logs, but that reports the size of each bin. If an entry is not in the map for a particular bin, then the size is 0. The structure of the log will be:
generation, size bin 0, size bin 1, ... , size bin last
Subpop log is working, excess code needs to be hunted down and deleted
Cleaned all the code I could find. Should now be consistent. Logging is successful.
This does not seem to be working. We're trying to restrict the sub-pops to 10, but getting much larger populations
When running in console it correctly restricts the subpopulation size, but when running MinecraftAccumulate-MOME-Observer-FlyVsMissileDirectSmallPOCapped.bat it does not seem to restrict the sub population size.
This needs more observation to understand.
I have a separate capped MOME run in my office where the populations are also not being capped, so I think there is definitely a problem. I'm skeptical that the console run actually worked, so this needs to be revisited. Extra assertions could help track the issue down.
Problem not fixed yet. Adding even more debugging code. Investigating alarming possibility that the method to filter down the bin population to a Pareto front isn't even working
After a night of running with none of the assertions tripping, and seeing the results so far on bin population size, I'm reasonably sure the issue has been fixed:
It was a synchronization issue, which makes sense in retrospect. We'll have to monitor execution speed in the meantime. For now, I'll close this issue, but I'm sure we'll notice if it breaks again.
@JoannaBlatt asked: "should we have a control for the number of individuals in a bin's population?" with respect to MOME #891
The original MOME paper did indeed impose a restriction of this sort, but they mainly did it for optimization purposes. I think that we can avoid doing this, at least in our first implementation. However, it could be useful in the long run to have this option.
So, complete MOME #891 first without any kind of restriction on the size of each sub-population. Then, after that seems to work, add a command line parameter for "maximumMOMESubPopulationSize" with a default value of -1. We will interpret -1 as there being no restriction, but if the value is a positive number, then there is a limit on the size of each Pareto front sub-population.
If we are limiting the size, and a given front/sub-pop is bigger than the size, then randomly remove individuals from the front until the size is in bounds.