Right now at Asirikuy we have a price-action system repository with more than 3 thousand active trading systems. However our repository is constantly changing since new strategies are mined every week and strategies that behave poorly are removed using several worst case metrics — mostly based on linear regressions and Monte Carlo simulations. This means that making portfolio simulations of the trading repository can be hard because we constantly change the systems that are available for trading and any accurate back-test of our trading arsenal should account for that. Today I want to share with you my journey in the creation of a software to perform these simulations in order to find portfolio construction mechanisms that yield better historical results.
–
–
The problem of performing the above simulations for us was that it was tremendously expensive. We implemented MySQL/Python code that would perform these simulations by performing database queries asking for the only systems that were active at a given point in time by using filters using the strategy creation and worst case dates. Portfolio performance was then calculated by querying the trade-by-trade performance of the strategies for the week and doing cumulative multiplication operations to figure out what the portfolio’s results for that week would be like. The simulations were done in this manner since we only add/remove systems during the week-end so in reality meaningful portfolio rebalancing steps can only be carried out during this time. For a complicated portfolio – for example a portfolio that used all available systems in the repository at each point in time – this might have taken many hours per simulation.
Having slow simulations problematic since it only allowed us to study the historical results from a very limited selection of systems and it was obviously impossible for us to have any chance of searching for historical selections that gave some sort of desired result. In order to better understand the role selection plays and patterns that may arise in more successful selections in terms of historical testing I decided to take this to the next level and implement a python/openCL program to perform this task. My idea was to create a program that would allow us to perform this simulations very cheaply and reduce the time necessary by at least 2 or 3 orders of magnitude.
–
–
The coding of this software was quite a challenge. Since everything in MySQL is neatly organized and easy to query I needed to come up with flat simple float arrays that would allow me to get the same information in a condensed manner. They needed to be small enough so that I could pass them without problems to the CPU/GPU I wanted to use but avoid any unnecessary simplifications that would ruin simulations. In the end I created a matrix using system weekly returns and another table containing system in-sample statistics and their creation and worst case dates (if any). In this manner I could use the weekly returns to construct the portfolio simulations and the in-sample statistics to address rule selections. With this program I could then quickly get the back-testing statistics for a historical simulation of something like “select systems with an in sample profit factor greater than 1.5 and a win ratio greater than 70%”.
The result was great, a gargantuan increase in computation speed. I mentioned that it took a few hours to get fairly complex simulations, now it takes around 0.5-2ms to get the same result (depending on whether I used my CPU or GPU). This not only means that we can now obtain the results for any rule selections we want but that we can systematically search rule spaces for those that give some desired level of statistical performance. In the above example I searched through a 121K rule space and found exactly 95 simple rule sets that gave me repository backtests with these characteristics: PROFIT_FACTOR>1.5, WEEKS_TRADING>10,AVERAGE_TOTAL_SYS>10, MAX_DD_LENGTH<50. A resulting rule that gave satisfying results in the software was to always select systems with in sample reward to risk lower than 2.35 and an in-sample expectancy greater than 0.43.
–
–
Of course I try to have no delusions. I am aware that finding rules that gave some sort of historical result in no way implies that that result will translate into anything useful going forward. I am also aware that the statistical significance of the rules selected needs to be closely monitored by ensuring that they always select enough systems and that they have traded for a long enough period of time, the complexity of the rules also needs to be very limited (right now for example we never use more than two conditions). However up until now there are some general patterns in the rules that give the best results, something encouraging that not only leads to a better understanding but to potentially much better trading results. If you would like to learn more about our trading repository and how you too can trade using hundreds of systems please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading.strategies.
