Progress Update 12

    If you have been following along with my progress, first off let me say: I am very grateful that you are interested in my learning process involved with trying to build this trading algorithm over this summer. By all means, this isn't the final progress report/blog post and there will be more to come. The reason I am saying this is that my progress will be significantly slowed due to me going back to college. My main focus will be shifted back to school work and pursuing a Bachelor's of Science degree in Economics and (hopefully...) an Undergraduate degree in Finance.

    This doesn't mean that I am done or finished with this little project of mine. I will make small progress on the algorithm whenever I have some downtime in my college life. But it won't be anything near the progress that I have made during the last 2 months. I will shift focus to this project during school breaks (Spring break, Winter break, etc.) if those situations allow me. But basically from now on, it cannot be my #1 focus. Anyways, let's see the culmination of my efforts from the past 2 months.

    Starting off of what I learned from the book: Conquering The Seven Faces of Risk by Scott M. Juds, I read that through his learning process he started off with the basic function of the algorithm as switching between the "fastest horses" by riding the asset/ETF with the most momentum. But obviously, there are times such as liquidity crunches and more drawn out recessions that affect all assets. So the strategy of riding the asset with the biggest trend is all sunshine and rainbows until everything comes crashing down.

    So how does Juds avoid these sharp downturns? He created a signal that notifies for imminent sharp downturns like recessions and then turns the algorithm off and flees to cash until the signal says otherwise. He calls this recession signal: StormGuard. Juds's first iteration of StormGuard is a lot less complex than his succeeding iterations. It is based on the second order exponential moving average (DEMA) of market returns to determine when the recession signal goes off and liquidates everything.

    Now one thing Juds points out is that his use of DEMA is the same use as people use in the physics and math world. Where "second order" just simply means the derivative of a derivative. In this case, then the formula for second order exponential moving average should just be:

    In the Finance world, there is actually a different equation to calculate the second order exponential moving average which is most commonly defined as:

    The reasoning that the Finance world uses a different calculation for the DEMA is because it is used to help indicator lag. But since Juds is already knee deep in calculating his algorithms using signal to noise ratios, which are more commonly used in the math and physics world, he might as well stick to the original definition of DEMA to calculate his recession signals.

    Starting from where I left off in the last blog update. I tried to take a stab at re-creating a recession indicator. Here is a picture of the results.

    As you can see in the chart, my "recession indicator" didn't avoid any recessions :(

    I tried different ways of re-calculating my indicator but was faced with similar if not worse results than the equity curve pictured above. In the pictures below, you can see the strategy's performance (in yellow) compared to a number of crises in which QuantConnect provides you in an automatically generated report.

    As you can tell, my "alarm" didn't function properly in any of these crises. In some crises like the US Housing Bubble 2003, my strategy lost less but that is still a loss and the eventual purpose for such an indicator is to avoid all of these entirely.

    The most interesting part about these is what was the Low Volatility Bull Market from early 2005 to mid 2007 pictured below.

    You can see that in most up-trends, the general strategy of switching to the "fastest horse" works brilliantly based upon what ETF tickers I gave the strategy to trade. But the failed attempt at trying to make a recession indicator heavily offset those nice gains.

    After running out of time to work on the algorithm, I decided that here was a good place to stop and kept reading the book for the past 2 days.

    I learned that after Juds created his StormGuard indicator, he moved on towards optimization of the actual "switching" to the "fastest horse". After extensive amount of testing with a various amount of methods to determine trend momentum: simple moving average (SMA), exponential moving average (EMA), and double exponential moving average (DEMA) with various period sizes ranging from periods of 63-125 days, he came to the conclusion that the best way to measure momentum is constantly changing. There is no indicator and period combination that consistently quantifies the fastest trends with 100% accuracy 100% of the time.

    So how can you solve this to further make the switching to the "fastest horse" more efficient and profitable? The answer is simpler than you think: by being adaptive. Juds calls this function of his algorithm: Automated Polymorphic Momentum. This is where the algorithm is constantly changing the momentum indicator and period and adapting to constantly changing to navigate current market conditions. As Juds says: "The team players set the speed of the game".

    

    My guess of how this works in the back-end is that for every symbol there is a vast set of different momentum indicators each with a vast set of different periods. And selecting the best momentum indicator with the best period for that select symbol at differing periods of time.

    That sounds super hard to implement on my own and if I was to take a crack at it, it could possibly take longer than 1 summer. In addition to that. On the free version of QuantConnect, you are limited to processing power since the actual calculation of the back-tests are done on a separate server, not your own PC. Even on that, when I was running one of my bask-tests with one set of indicator data for ~50 symbols, it was taking as long as 40 minutes to perform a 22-year back-test. So if I was to stay on the free version, imagine how long it would take to store XX different types of indicator data per symbol. That would probably set one of QuantConnect's server racks on fire. That would be something that I would implement in the future after I figure out how to get a basic recession indicator working.

    So, that was a big summary of what I learned from the past week as well as the product of my hard work this summer. I am far from done even though I never will be. There will always a better way and I will strive to find it.

I'll be back in a bit,

-Jamie