Water/Lava Count Characterization

[schrum2]

Do a behavior characterization for Water/Lava experiments that creates a 2D archive: number of water blocks vs number of lava blocks. This would count the numbers of these blocks in the original shape, not the result after simulation.

Can model off of MinecraftMAPElitesRedstoneVSPistonBinLabels

[schrum2]

For this, first make MinecraftMAPElites2DBlockCountBinLabels. This file should contain all of the code from MinecraftMAPElitesRedstoneVSPistonBinLabels, except that the class will be abstract, and the value of List<MinecraftFitnessFunction> properties will be set in a constructor that takes in the list as a parameter. Also, the hard-coded strings in this line should be changed:

labels.add("BlockCountRedstone"+i+"NegativeSpacePistons"+j); 

I don't know why it says "NegativeSpacePistons" and I think that is a mistake. It's actually just "BlockCountPistons". However, for the sake of generalizability, you can do something like the following for the two names:

properties.get(0).getClass().getSimpleName()
properties.get(1).getClass().getSimpleName()

This collection of changes removed any mention of pistons or redstone. Instead, the MinecraftMAPElitesRedstoneVSPistonBinLabels class can extend MinecraftMAPElites2DBlockCountBinLabels, and have pretty much nothing except for a constructor with no parameters that calls the super constructor with a hard-coded list of the redstone and piston count fitnesses.

Do all of this, Maven install, and verify that it works. If it does, then making a similar binning scheme for water and lava will be trivial (nothing but a constructor)

[schrum2]

IF the new CMA-ME batch file from #876 is able to run without crashing right away, then also make a batch file for this Water vs Lava approach that uses CMA-ME instead of plain MAP Elites.

[schrum2]

CMA-ME did not result in great coverage, so running with SBX now

[schrum2]

SBX also not much better. To some extent, it makes sense that it's hard to cover the space, since Water and Lava are each just one block out of 7 or so, but we should be able to get more variety somehow.

So, try one more experiment (don't need a batch file, just a main method in some class) where you use the now fixed water/lava count characterization, but the fitness function is simply NumLavaFitness. This should at least drive evolution to fill out one axis of the 2D archive.

[TjRaffert]

[TjRaffert]

This is the final result. It should have been able to explore more lava blocks better.

[schrum2]

Try this with integer-based encoding ( #886 ) too

[TjRaffert]

[schrum2]

Try a similar experiment with a new block set that only has two possible blocks (one might already exist, but you can make one if needed) and use a fitness function that tries to maximize just one of those blocks with the type count fitness. This should have a better chance of succeeding.

[schrum2]

I did this with a redstone/quartz blockset, a redstone vs quartz binning scheme, and a fitness to maximize redstone.

[schrum2]

However, results still aren't as good as they should be. Here is the archive:

[schrum2]

I'm going to try running for longer to see what happens.

[schrum2]

I had to produce 200000 individuals to get these results, and although they are better, they are still not great:

I'm going to change the mutation scheme

[schrum2]

Tried turning polynomial mutation off, but didn't get much better results

[schrum2]

Trying a much higher mutation rate: realMutateRate:0.7 instead of the usual realMutateRate:0.3

However, I think the next step is to have mutations that target individual genes rather than ones that span the whole genotype

[schrum2]

The higher mutation rate basically had no effect

[schrum2]

The new theory is that if too many indices mutate at the same time, then it is hard to push the search in any one specific direction. So, the new numVectorIndexMutations option can limit the number of indices in a genotype that are modified by a single mutation. Applied to both real vectors and int vectors (with some code repetition unfortunately), and am testing with real now. Might work better with int encoding though

[schrum2]

I think we're finally seeing a bit of improvement when we only allow a mutation to change one index of the genotype at a time.

[schrum2]

This has inspired a new genotype encoding #899

This issue can be closed.