{"id":26,"date":"2022-01-28T04:31:55","date_gmt":"2022-01-28T04:31:55","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/carltjoh\/?p=26"},"modified":"2022-01-28T04:31:55","modified_gmt":"2022-01-28T04:31:55","slug":"crazy-ivan","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/carltjoh\/2022\/01\/28\/crazy-ivan\/","title":{"rendered":"Crazy Ivan!"},"content":{"rendered":"\n

(For anyone who may be wondering, a \u201cCrazy Ivan\u201d is a maneuver for adjusting the direction of a ship.\u00a0 It became part of the broader pop culture after a reference in the movie Hunt for Red October<\/em>.)<\/p>\n\n\n\n

This week we learned that we would need to make a bit of a course correct in our project plan based on input from our sponsor (hence the title of the post).\u00a0 We had met several times to discuss the project and we were aware that our work would have to interface with existing code, which we received last weekend.\u00a0 However, when we reviewed the existing code, we realized that it functioned a bit differently than we had anticipated, which helped to surface some larger gaps in expectation.\u00a0 As such, we held a quick meeting with our sponsor on Wednesday to confirm our assessment and discuss the path forward.<\/p>\n\n\n\n

What is Changing?<\/strong><\/p>\n\n\n\n

Our initial understanding of the project was that we would seek to algorithmically identify a small group of securities which would be suitable for trading based on a momentum strategy.\u00a0 To this end, we were planning to develop functions which would measure volatility and momentum based on the preceding time period, which would in turn be used for predicting the relative strength of each asset during the upcoming period.\u00a0 From this data, we understood that existing code would construct a portfolio and initiate Buy\/Sell orders to implement the selection of a portfolio to be bought-and-held for a period of months.\u00a0 However, when we received and reviewed the existing code, we realized that it functioned a bit different than we anticipated, which surfaced some other gaps.<\/p>\n\n\n\n

First, the intent of our project code is to select a single volatile security with increasing momentum from a specified universe of candidate securities.\u00a0 The function of existing code will be to buy and sell this specified security repeatedly in response to shorter-term swings in momentum based on a daily level of resolution.\u00a0 Thus, our code might be run once monthly to update the selection of the preferred asset for trading.\u00a0 However, once the asset has been selected, existing code may buy and resell shares in response to momentum fluctuations multiple times before the asset selection is run again (as opposed to our initial understanding that the portfolio would be bought-and-held until the next selection cycle).<\/p>\n\n\n\n

Second, our code will also need to incorporate its own hypothetical performance from previous periods based on different asset selections as inputs to the logic of selection for the upcoming period.\u00a0 These will be additional to the volatility and momentum indicators that we were already planning to use as inputs, but this complicates the problem statement because we will have to run back tests for all assets in the defined universe and all time periods which we intend to consider as inputs for our selection algorithm.<\/p>\n\n\n\n

How Will This Affect the Project?<\/strong><\/p>\n\n\n\n

Below is the structural plan for the solution that we planned to implement.<\/p>\n\n\n\n

\"\"
Figure 1 \u2013 Planned project structure<\/em><\/strong> <\/figcaption><\/figure>\n\n\n\n

To elaborate upon the Security Scoring Module from the diagram above, following is a high-level overview of the logical process which we had envisioned:<\/p>\n\n\n\n

\"\"
Figure 2 \u2013 Planned implementation of Security Scoring Module<\/em><\/strong><\/figcaption><\/figure>\n\n\n\n

However, based on a review of existing code and the meeting with our sponsor on Wednesday, we will need to make two adjustments to how the application will work.<\/p>\n\n\n\n

First, instead of just initiating one-time buy\/sell signals to update the portfolio each time we choose a new security for trading, the Trade Signal Generator from Figure 1 above will actively generate multiple transactions based on a given security selection (before the next update in the security selection).\u00a0 Disruption to our plans will be fairly minimal since this is already implemented in existing code which will be downstream from our area of focus.<\/p>\n\n\n\n

The second adjustment will be a bit more disruptive.\u00a0 Aside from the user-defined configuration, the logic depicted in Figure 2 could be implemented solely on the basis of historical data from a third-party source.\u00a0 However, based on the call with our sponsor on Wednesday, we now know that we will need to incorporate inputs based on the hypothetical past performance of the algorithm itself, based on various asset selections.<\/p>\n\n\n\n

Why Does This Complicate Things?<\/strong><\/p>\n\n\n\n

Hypothetical performance of an algorithm can be measured by \u201cback testing,\u201d which refers to the process using historical data as inputs to simulate how the algorithm would have behaved if it had been implemented in the past.\u00a0 This approach has limitations (such as susceptibility to overfitting and past data\u2019s limited ability to predict the future), but it is often the best indication of likely performance that one can get without paper trading or actual trading in a live environment.<\/p>\n\n\n\n

We always intended to back test algorithms that we were considering for this project using QuantConnect Lean to get an indication of their possible performance.\u00a0 QuantConnect is designed to efficiently implement back tests and provide relatively detailed data about how the algorithm would have performed under the conditions specified.\u00a0 However, we did not anticipate incorporating back tests of multiple hypothetical cases as inputs for our selection logic.\u00a0 Doing so adds a layer of complexity because we are unaware of any way to efficiently trigger a suite of back tests and collect results for each using our code.<\/p>\n\n\n\n

What is the Solution?<\/strong><\/p>\n\n\n\n

Given enough time, we could create our own code to simulate the back testing functionality in QuantConnect. \u00a0However, since the primary focus of this project is not to reinvent existing software, we agreed with our sponsor that it would be a more valuable use of our time to collect results from a defined suite of back tests manually, save these in a table and then import this data into our algorithm for reference as needed.<\/p>\n\n\n\n

What did we Learn?<\/strong><\/p>\n\n\n\n

Frankly, this was mostly a success story.\u00a0 Although our team did not correctly understand all requirements for the project initially, we did realize there could be some confusion, had requested to review the existing code as a means of identifying any gaps, and proactively discovered the gaps early in the project.\u00a0 Our first lesson learned should be to always model this behavior of being attentive to possible expectation gaps and driving to clarity as quickly as possible.<\/p>\n\n\n\n

One root cause of the miscommunication was an imprecise\/inconsistent use of specific terms from the Finance industry.\u00a0 It merits noting for future reference, that this can be a common source of miscommunication, especially with a group is relatively new and stakeholders have not had an opportunity to align thoroughly on their use of jargon.<\/p>\n","protected":false},"excerpt":{"rendered":"

(For anyone who may be wondering, a \u201cCrazy Ivan\u201d is a maneuver for adjusting the direction of a ship.\u00a0 It became part of the broader pop culture after a reference in the movie Hunt for Red October.) This week we learned that we would need to make a bit of a course correct in our […]<\/p>\n","protected":false},"author":11946,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-26","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/26","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/users\/11946"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/comments?post=26"}],"version-history":[{"count":1,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/26\/revisions"}],"predecessor-version":[{"id":30,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/26\/revisions\/30"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/media?parent=26"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/categories?post=26"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/tags?post=26"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}