Simple Experiments with Width/Depth/Height simply to verify how well evolution searches

[schrum2]

Run some experiments that try to see how Width/Height/Depth behavior characterization covers the space with 5x5x5 shapes. We don't need a batch file, but you will need to have a main method somewhere, and you will want to save results to a directory on disk to be able to look at the archive during evolution.

Use a simple block set and fitness function. Just use the SimpleSolidBlockSet and the NumRedstoneFitness

Try with and without SBX crossover. Report within this issue thread on the amount of coverage of the space that you get.

[TjRaffert]

[schrum2]

Since the integer based encoding seems to be working #886 , I think the next thing to try is applying it here. So, use the same settings here: 5x5x5, WHD bins, simple fitness to maximize redstone, but swap out the shape generator and the genotype parameters so that the integer-based encoding is used. See how that goes and report on it in this issue thread.

[TjRaffert]

This is the results without SBX.

[TjRaffert]

This is the result with integer-based encoding.

[schrum2]

This is still frustrating, but still makes some sense to me as well. With a 5x5x5 shape, we have 375 numbers in the genome. In order for the width, height, or depth to reduce by 1, all values on the same face of the shape have to be absent. That means we are struggling to set 25 numbers out of 375 to the correct specific value, and that we also have no feedback/guidance in the meantime. The shape just has to stumble across the right answer.

Because of these challenges, part of me wants to just give up and accept that Width/Height/Depth is a bad behavior characterization, but there is one more thing I want you to try that really should work. Add the necessary code to make NumAirFitness be used by evolution (need command line parameter and need to add if-statement in MinecraftShapeTask). This should encourage evolution to make shapes with as few blocks as possible, which should in turn fill up many more bins in this type of archive than just one.

This has to work. If it doesn't, then there is some really big problem we need to track down.

[schrum2]

I've had a bit of luck with #879 by introducing some new settings. Try running with the integer-based encoding using these settings numVectorIndexMutations:1 polynomialMutation:false

[TjRaffert]

[TjRaffert]

These settings definitely seem to work. This only allows one mutation at once making the machine not work against itself.