Strange behavior in 1st and 2nd quartile

[GoogleCodeExporter]

The 1st and 2nd quartile are having problems gathering information from mtgo.
With the last updates the application is reporting a high number of expired 
connections (usually are the same two connections that are being dropped and 
recreated), while the gene visualizer show that the first 2 quartiles have much 
less information than the other two.
I am attaching the gene visualizer of a old version (commit 320b6b39cc15) and a 
new one (commit 11fbbefe3aa3) both with a difference of a few hours.

Original issue reported on code.google.com by andremos...@gmail.com on 22 Dec 2012 at 7:01

Attachments:

• gene_visualizer_11fbbefe3aa3.html
• [gene_visualizer 320b6b39cc15.html](https://storage.googleapis.com/google-code-attachments/ga-bitbot/issue-41/comment-0/gene_visualizer 320b6b39cc15.html)

[GoogleCodeExporter]

This is normal. The reason you're seeing this behavior is that the fitness 
function can not find suitable genes in the lower two quartiles and the 
gene_server filters out any submitted genes that did not result in a trade.

In the gts.py script, each time the population is fully scored, the local 
optima buffer captures the highest score. Local optima is detected when the 
buffer is filled with the same score. This indicates that no further progress 
is likely with the test population. And with the run_once option set when 
launching gts.py, the script will 'expire' when this condition is reached.

So one reason your seeing greater expiration rates for the lower two quartiles 
is that the local optima condition is triggered with the absolute minimum 
number of population cycles required due to no advancement in fitness scores. 

The second contributor is that the fitness function runs faster when no trade 
positions are generated. This is because the fitness function code to manage 
trade positions is never executed. 

The reason the gene visualization for the first two quartiles are of differing 
lengths is that the gene_server wont accept submissions for the lowest score: 
if d['score'] != -987654321.12346:

Differences in performance between commits can probably be attributed to 
changes in the gene_def config. I regularly change it for testing purposes.

Thanks for the issue submission, I'll add this note to the FAQ.

Original comment by brian.mo...@gmail.com on 28 Dec 2012 at 8:25

• Changed state: Invalid