all the scores calculcated as -0.12346

[GoogleCodeExporter]

All the clients caclulate the scores as -0.12346. Latest git. confirmed with 
old db, blank db and both gts.py 'y' and 'n'.

Thank you for all the hard work!

Original issue reported on code.google.com by purge...@gmail.com on 3 Mar 2012 at 12:02

[GoogleCodeExporter]

There was a corner case bug in the system where databases were getting cross 
contaminated after running for some time. I created a few different gene_def 
configs and loaded them into the library, one of them being an almost 
impossible to trade config. 

The bug has been identified and corrected but the impossible gene_def config 
was posted to the repo. It was trying to find very high markups; The system may 
find orders in the fourth quartile but it would never trigger in the lower 
ones. The -0.12346 score is built in to bct and is set whenever a gene results 
in zero trades.

So this isn't a bug. It was a poor gene_def config not finding any trades.

Original comment by brian.mo...@gmail.com on 3 Mar 2012 at 3:25

[GoogleCodeExporter]

What's the name of offending gene_def config? 'big money' or 'very high'?

With latest git version, 'big money' as the only config indeed does not find 
any trades. 'very high' found only q3-q4 trades, so I'm not sure which one is 
the guilty party.

Does that mean the rest of databases should be considered contaminated, 
deleted, and I should start breeding a new batch?

Original comment by purge...@gmail.com on 3 Mar 2012 at 4:33

[GoogleCodeExporter]

*correction - 'big money' does seem to find trades, but at much slower pace 
than previous configs I ran from the scratch. Will leave it running for a day 
or two, and report back if I do find anything wrong with it.

Original comment by purge...@gmail.com on 3 Mar 2012 at 5:00

[GoogleCodeExporter]

The system will repair the library. However, the amount of time that it will 
take depends on the overall speed of the system and how many databases are in 
the library.

Original comment by brian.mo...@gmail.com on 3 Mar 2012 at 5:50

[GoogleCodeExporter]

Not sure how long will it take with my resources to repair the library, but 
there are still no trades in Q1 in any of the configurations, max 2 trades for 
the best genes of the Q2s, double digits in most Q3s, and triple digits of 
trades in most Q4s. Will report back in a day or two if the system still does 
not manage to improve the best genes.

Original comment by purge...@gmail.com on 5 Mar 2012 at 3:53

[GoogleCodeExporter]

After another 10 days of crunching, and still 0-1 positions in Q1-2, and <25 
positions in Q3. Q4 Same for both 'big money' and 'very high' configs. Using 
latest git. Are you sure it's going to repair itself? =)

Original comment by purge...@gmail.com on 16 Mar 2012 at 10:43

[GoogleCodeExporter]

The repairing comment was in regards to cross contamination. That should be 
cleared up now.

Regarding the low number of trades, after playing around with the new gene 
library setup and trying different configs this is what I would recommend:

1) Delete the gene configs with high markups (use the db_admin_util.py). High 
markups result in very low trade opportunities.

2) Create a gene_config with a small markup with the stop loss set to around 
five times that. Make sure the mark up is greater than 2x your commission. The 
higher stop loss, while increasing risk, will give the system more wiggle room 
to find the optimum configuration. Make sure 'enable_underbids' is set to one 
in the global_config. 

Use the web client to set the low markup config as the default: go to the 
system monitor page and click on the corresponding gene_def hash link to set it 
as the default (this needs to be done every time the system is restarted and 
can also be changed anytime the system is running).

The underbid system in bcbookie will create a series of orders with increasing 
markups and increasing shares. 

This setup will generate the highest number of buy triggers while still 
providing an opportunity for higher markup trades.

I'm also not seeing much of anything happening in the first two quartiles 
regardless of the markups. I guess this makes sense as without volatility 
(which would increase the quartile state) the system can't find any potential 
trades.

Original comment by brian.mo...@gmail.com on 20 Mar 2012 at 1:46

[GoogleCodeExporter]

I see a similar pattern. I've been running a 1.5-2.5% markup gene_config for 
the last 72 hours on the latest git version and no orders have been placed at 
all in Quartiles 1-3. On the status page, though, quartile 3 says it has 20 
positions with 20 wins. Doesn't that imply orders? There hasn't been much 
volatility in the last 72 hours, but shouldn't some orders match those 
quartiles still with these kinds of settings?

Original comment by Jeff.Mi...@gmail.com on 30 Mar 2012 at 8:37

[GoogleCodeExporter]

Almost the same situation here - 1.2-2.2% markup, few days runtime, q1 reports 
0 positions, q2 1 position and 1 loss, q3 reports 20 positions and 20 wins, and 
q4 Wins: 376; Loss:9; Positions: 385 with score: 29859.9742435. Almost 2 days 
of calculations have passed and no significant change was noticed =(

Original comment by purge...@gmail.com on 31 Mar 2012 at 6:57

[GoogleCodeExporter]

There seems to be some confusion regarding the gene_def configs. 

The gene_def configs that make their way to the repository are test cases which 
also demonstrate the capability of the format -- they are not always intended 
to be profitable configurations. 

The intention was that users would create their own configurations based on 
their own trading goals; Whether it be low margin high frequency trading or 
high margin long term trading the gene_def should have the capability to 
support any trade strategy.

I don't see this issue as a bug but rather a need to clarify to the end users 
on the need to develop their own gene_defs along with providing better 
documentation and tools to support the users doing so.

To specifically address what was happening, the gene_def configs simply could 
not find buy opportunities in the lower volatility quartiles. 

To help alleviate this issue I changed the default ATR (average true range) 
window in bct_alt.py (which is replacing bct.py) to a shorter period to allow 
faster switching between quartiles. 

But again the long term goal is that users can write their own fitness 
modules/trade engines to be optimized. It's not quite ready yet, I still need 
to lock down a generic fitness module interface that can be developed to.

Finally, the gene_def format has been expanded to specify and allow direct 
configuration of the fitness modules/trade engine. This will allow things such 
as the ATR to be specified on a per gene_def basis.

Original comment by brian.mo...@gmail.com on 2 Dec 2012 at 6:37

• Changed state: Started

[GoogleCodeExporter]

See here for additional discussion regarding the scoring algorithms used by the 
bct*.py fitness classes:

http://54.241.21.48/phpbb/viewtopic.php?f=4&t=8&sid=e042b0214ef068b2de94d477ad38
0791

Hopefully this gives some insight and sparks some ideas for individual 
customization or providing feedback on suggested improvements.

Original comment by brian.mo...@gmail.com on 6 Mar 2013 at 2:09