Closed GoogleCodeExporter closed 8 years ago
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.
Original comment by brian.mo...@gmail.com
on 27 Mar 2012 at 10:42
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.
Original comment by brian.mo...@gmail.com
on 29 Mar 2012 at 4:24
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 =]?
Original comment by purge...@gmail.com
on 29 Mar 2012 at 8:24
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 ;)
Original comment by purge...@gmail.com
on 29 Mar 2012 at 1:27
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).
Original comment by brian.mo...@gmail.com
on 14 Nov 2012 at 11:46
Original comment by brian.mo...@gmail.com
on 28 Dec 2012 at 8:34
Issue 53 has been merged into this issue.
Original comment by brian.mo...@gmail.com
on 23 Feb 2013 at 3:00
Original issue reported on code.google.com by
purge...@gmail.com
on 23 Mar 2012 at 10:16