Report_gen seems not to use the right set of data about ga-bitbot HOT 7 CLOSED

I recently added a score_only option to gts.py. However, when this option is 
used (and it is used by gal.py) gts was mating them before scoring. This bug 
can result in a 'stale' gene being reported. When report_gen receives the gene 
it is scored again (although not reported to gene_server) in order to generate 
the charts.

Quartile: 4 (29725.3666)  <- Old stale score as stored on the gene_server
...
Score:  -1445.21898857   <- Current score as calculated by report_gen


In the case above, the previously high scoring gene is now underperforming.

Under normal operation, it is common to see differences in these two scores, 
depending on how long ago an update was submitted to the gene_server. This is 
why in gal.py there is a dedicated client that does nothing but update all the 
genes for the default gene_def config db: 'pypy gts.py all y run_once 
get_default_config score_only'.

bug fix is on the repo.

After further investigation another issue was found in wc_server. 

A local variable name (pid) was reused in a 'for' loop construct. This means 
the high score reported was not necessarily for the default gene_def (as used 
by wc_server) but rather the gene_def used by the last client reported in the 
previous section of the report.

fixed on repo.

Hello,

Unfortunately, even with latest fixes, the report_gen and wc_server do not get 
along:

wc_server reports:
Quartile: 4 :: Thu Mar 29 10:25:06 2012
buy_wait: 1
stop_loss: 0.065
generation: 115
markup: 0.02323
wls: 1
shares: 5.12
msg: Balance: 1090.88795674; Wins: 367; Loss:12; Positions: 379
score: 29725.3665826
wll: 436
time: 1333008716.72
buy_wait_after_stop_loss: 28
macd_buy_trip: -5.28
gene: 
11100001100000100000000000000000000000110111111111111000000000000000111100010001
000000
stop_age: 241
id: 00609413881-24fb98028002abd0

...and report_gen reports:
Quartile: 4 (29725.3666)
Inverse MACD Result (target):  4.51547868524
Last buy order was 3116 periods ago.
Score:  2857.00591755
creating charts...
log_orders: sorting data
log_orders: generating html table for 109 positions
chart: compressing data
chart: selecting data
chart: filling the template
chart: writing the data to a file
log_orders: sorting data
log_orders: generating html table for 109 positions
chart: compressing data
chart: selecting data
chart: filling the template
chart: writing the data to a file
log_orders: sorting data
log_orders: generating html table for 109 positions
chart: compressing data
chart: selecting data
chart: filling the template
chart: writing the data to a file

...please, do notice the number of trades is different, and that the score that 
report_gen does mention in it's first output line the same score that wc_server 
reports, but proceeds to use/report the different gene/score. Would it help if 
I sent you my whole ga-bitbot directory [without the .git subdirectory, of 
course =]?

Started anew with a clean install [I changed the markup and 
buy_wait_after_stop_loss in gene_def.json], and the numbers from report_gen 
output and htmls and wc_server do not match up. Should be easy enough to 
reproduce ;)

This is a combination of a couple of issues:
The selection method for the report_gen and wc_server are not the same.
- wc_server reports the all time high score
- report gen uses the highest scoring gene, scored within a certain time frame. 
This prevents older scored genes from being actively traded.

Closer investigation found that the genes which would fall out of favor and 
score below the killl score threshold when being retested were not being 
updated in the database -- allowing the old good scores to persist while in 
reality they now perform poorly. This additional issue has now been fixed -- 
When updating the scores, poor scoring genes are now deleted from the db. 

The original reported issue highlighted the secondary problem. However, the 
behavior of report_gen to only use recently scored genes is a method of 
protection to prevent old genes from being actively traded. 

The option to score_only in gts, to update the scores in the db, along with the 
aforementioned fix should alleviate the issue of stale data persisting in the 
db but provides no assurance that wc_server and report_gen scores will match 
(again considering the time windowed approach used by report_gen).

Issue 53 has been merged into this issue.