rtNEAT explore/exploit behavior

[GoogleCodeExporter]

Purpose of code changes on this branch:

When reviewing my code changes, please focus on:

After the review, I'll merge this branch into:
/trunk

/source/ai/rtneat/rtneat.cpp

Three is a particular section of the next_organism code which is supposed to 
handle Exploit behavior -- is it working correctly? 

this is under /branches/nero, but this goes back to that last version of the 
code hosted on here, as far as I can tell.

Original issue reported on code.google.com by AdamDz...@gmail.com on 8 Jul 2010 at 8:18

[GoogleCodeExporter]

Set review issue status to: Accepted

Original comment by ikarpov on 13 Jul 2010 at 5:01

• Changed state: Accepted

[GoogleCodeExporter]

Set review issue status to: Started

Original comment by ikarpov on 13 Jul 2010 at 6:03

• Changed state: Started

[GoogleCodeExporter]

Original comment by ikarpov on 13 Jul 2010 at 6:17

• Changed title: rtNEAT explore/exploit behavior

[GoogleCodeExporter]

The simple fix suggested in the line-by-line review didn't work. We decided 
that the problem is that the elite individual gets re-scored (potentially many 
times) and thus can get a fitness lower than the rest of the pool, leading to 
it not being re-selected again.

The way to solve this is probably to just ignore any fitness values received by 
the elite (exploit) organisms. That way, they will still participate in the 
Z-score for other organisms, but will not themselves be affected.

Reassigning back to Adam for implementation.

Original comment by ikarpov on 14 Jul 2010 at 9:37

• Added labels: Component-Logic, OpSys-All, Performance

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

SetFitness was modified to only work when fitness is 0, this appears to have 
fixed the problem. This change was committed to merge. It still needs a little 
bit more thorough testing.

Original comment by AdamDz...@gmail.com on 21 Jul 2010 at 7:18

[GoogleCodeExporter]

I tested this some more and this is pretty clearly working correctly now. The 
only possible problem is that in more complex situations based on the movement 
of others Exploit can choose a non-optimal solution, but that's more of a 
problem with the theory than the implementation, so I'd say this change can be 
safely merged into trunk.

Original comment by AdamDz...@gmail.com on 11 Aug 2010 at 2:08

[GoogleCodeExporter]

This has been merged into trunk - we should keep an eye on it but I am marking 
it fixed for now.

Original comment by ikarpov on 18 Aug 2010 at 3:00

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by ikarpov on 24 Aug 2010 at 7:08

• Changed state: Verified