Change Center of Mass Needs to Work with Missile Fitness

[schrum2]

As mentioned in #884, you ChangeCenterOfMass assigns incorrect fitness when combined with MissileFitness. This needs to be fixed in the following way:

In ChangeCenterOfMassFitness, within the fitnessResultForFlyingMachine method, there are two cases when the code believes there is a flying machine. However, all it is really checking is whether all or at least a sufficient number of blocks have departed. It is easy for machines with TNT to trick this fitness function by blowing themselves up.

So, all of the code inside of fitnessResultForFlyingMachine needs to be inside of an if-statement, though you may also need an additional helper method for this. The extra condition that this new if-statement is checking for is that every step within the shape's evaluation history is different. At least, this is what I want you to try first ... I worry it will be a bit too restrictive, so we may soften the requirement later.

Note: the first entry in the history should be skipped, since I think it will always match the second.

The other concern I have is that the shape may move and fly away, but the last two history entries (or more?) may match. So, maybe the history just has to have some number of distinct entries?

This will require trial and error, and also testing

[JoannaBlatt]

Ran but shapes immediately got max fitness. It is rewarding blowing up and not movement. Probably it's checking both block list and movement rather than just movement.

[JoannaBlatt]

started purposely inputting block shapes but had to stop

[schrum2]

Added @TjRaffert to the issue. We have some unit tests in ChangeCenterOfMassFitnessTest that attempt to see if a machine that causes explosions can properly be assigned a flying fitness. Basically, machines that explode sometimes fool the ChangeCenterOfMassFitness into thinking there is a flying machine.

As a starting point, we need a unit test that instantiates one of these shapes that we know explodes, and should not earn credit for being a flying machine. You'll need to manually construct this shape.

[JoannaBlatt]

ID121_.txt

[JoannaBlatt]

Got the unit test to work. I had to add code to fitnessResultForFlyingMachine where it checks if shape is empty and after the checkCreditForDepartedBlocks check, before it returns results. This means it checks the shape history for movement when all the blocks are gone or when only some blocks are gone.

[schrum2]

Here are some specific cases that need testing eventually.

Within ChangeCenterOfMassFitness:

• A shape that just blows up pretty much right away, leaving nothing behind
• A shape that just blows up pretty much right away, leaving at least one block behind
• A fully functioning flying machine with some TNT that activates right away, and blows up the machine mid flight

Some tests will also be needed of the missile fitness function, in a new test file just for that.

• Explosion happens but does not damage target at all
• Explosion obliterates target (put close enough to assure this)
• Target is far away and there is a flying machine that carries TNT to it to blow it up entirely (may be hard to figure out)

For that last test (and maybe some others), we want to test the multipleFitnessScores method in TimedEvaluationMinecraftFitnessFunction to make sure it can return correct values for both fitness functions from a single evaluation.

[JoannaBlatt]

testChangeInPositionWithRemainingBlocks this test enters shape history, has a history size of 9 but never enters the for loop and I can't figure out why. It passes, so I may just leave it alone for now.

[JoannaBlatt]

Doesn't enter history check: oscillating (size 8, no for loop) does enter history check: testChangeInTotalDistance (size 8) - does not enter for loop testChangeInPositionWithRemainingBlocks (size 9, no for loop) testTNTwithFlyingMachine (size 3, enters for loop) testTNTnoMovementLarger (size 23, enters for loop) ----fails

size 8-no for loop 22 - small for loop, 2 loops

currently only testTNTnoMovementLarger doesn't work - it is commented out for now

Tnt with flying machine gets wiped out before it can actually explode

[schrum2]

After all these changes to the fitness function we need to run some of the GECCO batch files to verify they still work

[JoannaBlatt]

Successfully ran GECCO batch files and produced flying machines. Seems like shapeHistoryCheck is working out well. Could use some work probably, but every unit test works now and it builds successfully.

[schrum2]

This issue is being re-opened @JoannaBlatt .

The commit from Travis (grab from his branch) has the new unit test which fails, and also had TODO comments at the parts in the code where the fix is needed.

[JoannaBlatt]

I deleted some code related to farthest center of mass, but it was the oscillation detection. I added in a check for it and it works. Could probably even make it so oscillating machines end early. I will work to get the code to be like final code instead of crappy rough draft.

[schrum2]

Don't end oscillating machines early

[schrum2]

This has definitely broken some unit tests. I think we need to keep the tests the same (mostly), but fix the fitness function

[TjRaffert]

testOscillatingMachine is getting a small decimal when it should be getting a score of greater than 30. testChangeInTotalDistance Expected max distance. testFlyingRewardSpeed is fully failing. testTNTwithFlyingMachine expected 8 but got 2.4 testChangeInPositionWithRemainingBlocks is getting false instead of true.

[schrum2]

I'm taking over this issue. Latest commit shares some useful information.

[schrum2]

@JoannaBlatt and @TjRaffert : merge my branch and see if you can Maven install this. I think it will work now.

[schrum2]

We have at least one example where flying machines evolved without explosions creating false positives