OmniVest User Forums
User-Created Portfolios
Ideas for Portfolio Wiz/Bal Iterative Process
13 replies, 1477 viewings
|
OmniVest User Forums
User-Created Portfolios
Ideas for Portfolio Wiz/Bal Iterative Process
|
Last Activity 7/22/2015 8:11 AM 13 replies, 1477 viewings |
|
|
|
| Printer friendly version |
Jim Dean Elite   Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA  User Profile |
The engine iterates (repeatedly iterates) through "columns", each of which represents an arbitrary "time slice" ... probably once a month or once a week, across the big historical window. Clearly, smaller slices will eat proportionately more CPU cycles. So, the question is, how small is small "enough"? The answer to that probably has to do with the combination of two other questions: 1. how quickly does the "market state" change that might drive a need to change portfolios? 2. how quickly does the overall performance of portfolios (or of their component strategies) change? I believe that both of these questions have DYNAMIC answers ... that is, there is no one "best" time-slice-interval that satisfies them, without "wasting" a lot of cycles during which the "slices" give identical results. So, I'm proposing that the DURATION of the columns of the internal tables that PortWiz/Bal is iterating through be built based on formulae rather than on arbitrary fixed time intervals such as a week or a month. Sometimes the formulae might call for the "minimum allowed" interval such as a week (gotta limit it to some minimum) ... but I believe that it's going to be quite common for the relevant conditions (ie market type or general ranking of portfolios, etc) to extend for a lot longer than just one week or even just one month. If that belief bears out ... then it's possible that the CPU resources required for doing Wiz/Bal runs could be cut by a significant percentage, without losing the benefit of fine resolution when it's needed. By "significant" I'm guessing at least 30% reduction in iterations, all else being equal, if the minimum slice size is one month ... and maybe as much as a 70% reduction if the minimum time slice is one week. These are just guesses of course. When I speak about driving the duration of each interval by a formula, here are some examples of how that might be applied. It's of course necessary that the formula that drives the decision be based on INDEPENDENT variables so as not to create a recursive nightmare. 1. Use a formula that is based on some simple or complex model of what "mode" the market is in ... a very simple example might be the one that Ed showed in the webinar ... C greater than three EMA's. The dataseries used for this might be the SPX ... many other rules might be used. 2. Use a formula based on the DELTA in relative equity-curve performances of each of the portfolios ... this could be keyed to some specific metric, or could be "voted" by several metrics that are a func of equity ... the point is that all that info is pre-calc'd before the iterations begin, so as not to be recursive. 3. Some combination of 1 & 2 would certainly be possible ... that is, if EITHER of the two rules dictated an interval-slice might be needed at some point, then that could be the rule ... or it might require that BOTH rules had to trigger, etc. Again ... the purpose here is not to introduce any additional complexity to the search-algorithm, other than the "boundaries" of each slice, which would be determined before the loop began. I hope this, or some variant of it, will help improve efficiency and thereby open up the servers to be able to handle other important factors such as Postion Sizing impacts. | ||
| Steve Mayo Legend  Posts: 414 Joined: 10/11/2012 Location: Austin, TX User Profile |
I think, however, it would add a significant level of complexity beyond what you are describing. Let me try to explain. First, a quick primer. The first step for the port switcher is to build a large table with ports on the y-axis and period-ending dates on the x-axis. If you are switching weekly and testing over 14 years, the table will have 728 columns and, lets say, 50 ports in the list for a total of 36,400 cells, each holding the result from a "scoring" function, say a 7-period RSI. Then, you rank-order the scores in each column and use the "winning" port for the forward month as you stitch-together the switched equity curve using the daily return data. Simple enough, until you start asking the obvious questions: is RSI or MACD best? Should it be a 7-day or 14-day RSI? Is it better to limit the switching to some subset of the ports? You add another 36K calculations for each permutation of those questions and your data "cube" gets very large. Yes, reducing the number of columns is desirable and your idea has merit if, say, OV-Pro could default to monthly columns and then only dropback to weekly during a bear market. But that presumes that each of the 50 portfolios reacts to the market mode in a similar fashion. That may be an incorrect presumption. In the accompanying graph (careful, don't compare ending equity as they do not have the same starting equity), notice the difference in slope and volatility in my TPM and Nirvana's ARM4 port from Nirvana's Bearish/Bullish pair on any particular month, and how both are quite different from the market. Thus, I think we only end up with another question (albeit a good one), what's the best periodicity to use for each port-set with a given indicator and its settings? To answer that would require yet another dimension in our data cube. I think we can accomplish something akin to what you are asking by treating the market's equity curve as another indicator. With that we could do something like linreg(Return("equity") - Return("QQQ-200%") to measure each portfolio RELATIVE to the market. Ed has said he would look into adding that to the available formulas. EDIT: Hmm, now that I see it posted, that QQQ line doesn't look right; it might be monthly data instead of daily like the others. I'll check and repost soon...but hopefully you get my concern. [Edited by Steve Mayo on 4/10/2014 10:37 PM]  Attached file : 2008.png (115KB - 682 downloads) | ||
| SteveL Veteran Posts: 189 Joined: 10/11/2012 Location: Boulder, CO User Profile |
[Edited by SteveL on 4/11/2014 8:23 AM] | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
You said "But that presumes that each of the 50 portfolios reacts to the market mode in a similar fashion." I must have explained my idea poorly - that presumption is not in line with or relevant to my thesis nor to the enhancement I proposed. I actually discussed this with you and Mark a long time ago when you were first developing this architecture. But the exigencies of excel implementation precluded its use (as well as other factors). I have tried to describe this as two separate processes - one being a very simple and non iterative prelim analysis of some algorithm (I suggest two general kinds but no reason it would have to be either), which would determine the necessary and appropriate columns that in turn would be used by the multi-layered iterative search and optimization analysis process. Of course we expect that each portfolio will have different characteristics - that is still very much a part of the iterative process. My earlier description was not intended to deny nor supplant nor attenuate those distinctions. I'm sorry for creating confusion. Ed specifically asked me not to get too detailed - and since I don't have a copy of the project spec, it's hard to pinpoint how and where the minor alterations might be made in it. I believe that this would not change the flow of what you've planned at all - it would just make the process more efficient. Oft-times we can get so engaged in the details of finding solutions that we lose sight of the driving forces and belief systems and fundamental processes that are the "background" in which the "experiment" resides. I've had to fight that tendency my entire adult life - I think all creative people need to be careful about it. Thus the Aristotle quotation in my signature-line. What I was trying to do was to SBAS (Step Back And Squint) and think about what the engine was trying to accomplish - and impose upon that the underlying belief that trading is only successful if one is aware of how the market changes over time, as a whole, and to remain adequately flexible and adaptable to respond to those changes in a fluid and timely fashion. You probably recall my proposal for a matrix of nine market states: three trend modes in conjunction with three volatility modes. In our (you and Mark and I) early discussions that seemed to be one of the goals - to be responsive to those changes when and as they occurred. It seemed serendipitous to me that such a focus, using natural market mode changes to establish timing, could also reduce the number of iterations needed. It's my hope that this idea, which was proposed very early on in the infancy of OmniVest, and elucidated in detail before OVest was even on the drawing boards, will be given much more careful consideration. But, even without it, I'm incredibly impressed by the work y'all have done - and I'm confident that the solutions which the PortWiz/Bal engine will produce will be excellent ones! [Edited by Jim Dean on 4/10/2014 11:08 PM] | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
Weekly slices are certainly best - the architecture needs to provide for that degree of resolution. And if OVest takes on intraday trading in earnest, DAILY slices might well be needed. My point is that a small and efficient non iterative preliminary analysis might add some extra "intelligence" as to WHERE to draw the weekly or daily boundaries. Those boundaries might be very compressed during some years with dozens of changes within that year. But for other years, the contrition of the market - it's personality - might remain in the same "domain" for months on end - so there would be no need to iterate through each week or day during that time. OVest should be smart enough to provide for both - the fine granularity and the more extended states. I hope this process has not already gone so far that it's cast in concrete. I may well be wrong about this being beneficial to the degree that I guesstimated - but I can't see that it would be harmful - and adding a little bit of extra code to test it out would be warranted, since if the thesis is proved, both Nirvana and all it's customers would benefit by the efficiency enhancements. [Edited by Jim Dean on 4/10/2014 11:05 PM] | ||
| Steve Mayo Legend Posts: 414 Joined: 10/11/2012 Location: Austin, TX User Profile |
| ||
| Mark Holstius Elite  Posts: 744 Joined: 10/11/2012 Location: Sleepy Hollow, IL User Profile |
Steve & I are currently limited by the capabilities of Excel, but I wrote a new macro that again switches between 2 portfolios to test my theory. It chooses from a universe of 40 different selection "factors" (RSI, etc) based on their performance over the previous 6, 5, 4, or 3 month periods. The universe of factors doesn’t change, just the number of months used to select the best performing one over that X month period - and then that factor is used to choose the one portfolio of 2 to use the following month, rolling forward one month at a time for 7 years. In other words, the only variation in the 4 algorithm setups is the BT period. The results are quite different for the 4 periods. The image below has the dates on the left and columns to the right for the results for the 4 periods. If the chosen port was the best of the 2 for the following month, the cell is green - if not, red. I’ve computed the results for switching using the 4 BT periods, and they’re located at the bottom of each column. The equity ranges between $6.9M (64% of months correct) and $10.8M (71% of months correct). If we could determine at the EOM whether to use the 6, 5, 4, or 3 month BT choice, the results would be improved rather dramatically. ($15.4M and 82.6% correct) Over this 7 year period (1/1/07 to 1/1/14), there was only a need for 6 changes from one BT period to the other - and during many periods there was considerable agreement and overlap between the results for the 4 different BT periods, so the “Market State” rule would not have to be too sensitive or stringent. In only a couple of cases is the move an “abrupt” one; #1 - any time during a 4 month period #2 - any time during a 9 month period #3 - any time during a 3 month period #4 - any time during an 8 month period #5 - any time during a 7 month period #6 - any time during a 2 month period The results for simply changing the BT period those 6 times are in the column to the right: $15.4M and 82.6% of months the correct portfolio is chosen. Note: these are true "walk forward" results (not curve fit over past data) and Ed's excellent ARM4 yields $4M over the same period. Jim - you’ve done a lot of work to quantify “Market State” identification, so I wonder if this might be possible? Mark [Edited by Mark Holstius on 4/13/2014 7:28 PM] Attached file : Market State Switching.jpg (1303KB - 623 downloads) | ||
| Mark Holstius Elite Posts: 744 Joined: 10/11/2012 Location: Sleepy Hollow, IL User Profile |
What we need is something that "triggers" for any of the conditions (6, 5, 4, 3 Mo BT) at the EOM when that particular condition's cell is green. That's the "target" for the Market State indicator. i.e. - on 1/31/07 it can trigger any of the 4 conditions, on 4/30/07 it would only trigger the 6 month BT, and on 11/30/07 it could trigger 6, 5, and 4 but not 3... etc Mark | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
My personal approach to market state is more directly tied to price rather than a doubly-derivative indicator such as RSI (et al) … but what you've done lets the market "pick out" which indicator is most expressive of it AT that time, without having to develop some deep theory about it. Sort of a GA or CB kind of thing, yet in excel. Cool. I suppose there could be quite a few good paradigms to consider to use as the "guiding light" for market state changes. I do like yours very much. My approach is more "theory" based, tied to Variable-Lag MA characteristics (slope and stacking mainly), applied to raw price and to price volatility, normalized into the nine states I mentioned. Mine would probably take about 2-5% of the calc's that your method did (but may not be as good as yours). Either way however is chicken feed compared to the massive main nested WizBal set of iterations across the time slices that are selected. (Btw - I might be incorrectly interpreting how your process works - whether the 40-indicator decision-making is done outside of and preceding the main iterative loop, or whether it's an integral part of it. My suggested approach precedes the loop so that it can dictate to the big loop what timeframe windows to use). And that was the main point of the suggestion that I was trying to propose - exactly what you demonstrated in your experiment - the number of time slices needed to do the calc was very dramatically cut - less than a tenth as many - which, if that was applied to the remainder of the massive iterative algorithm used by PortWiz/Bal, would really make a big difference in CPU time. THANK YOU very much for devoting serious time and effort to check this out and provide such an effective illustration of it. Whatever the "mechanism" for determining the times when a change is needed might be, I hope that the PortWizBal engine in its early incarnation will at least provide "hooks" so that later on, preprocessing can become an option, to cut out >90% of the iterations (6 dynamic slices in 7 years = 6 / 84 = only 7% of iterations required), in Mark's example. It would be a cool thing that the "Pro programmer" could code INTO - that is, we might individually come up with a bunch of very different, unique switching approaches - if the core WizBal engine could be "driven" by those uniquely-coded-by-clients creative viewpoints, I'll betcha that a huge amount of CPU time could be saved - and who knows? maybe some logic like yours or mine might even work out better than prolific CPU-glutton arbitrary slices, by preventing "portfolio whipsaw" affects. Heh heh - portfolio whipsaw - outside of OVest, who'da ever thunk such a consideration might ever come up? Anyways - thanks again. A perfect illustration of what I was suggesting, so that the servers are not so tied up, and so Nirvana could allow greater latitude than just 3 options per customer. I realize that might not appear right away - but I hope the architecture of the orig spec will make allowances for it to be added later without significant rework. [Edited by Jim Dean on 4/13/2014 10:20 PM] | ||
| Pete Taylor Member Posts: 28 Joined: 10/11/2012 Location: N Bradley, England User Profile |
If you look at the VIX on weekly bars - file attached, I would suggest that as increases say above 20 would trigger the need for "weekly slices". This to me would suggest potential changes in the market state, now happening. In bear markets these are generally very volatile periods, whereas bull markets can also be volatile towards the end of the cycle, but they are normally quiet periods, where prices steadily rise but volatility is low. A link to this would surely by definition alert us to areas in the market where we would need to look at things more often, as they are changing more quickly. [Edited by Pete Taylor on 4/14/2014 4:57 AM] Attached file : VIX weekly.PNG (270KB - 256 downloads) | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
Once again, the purpose of this thread was MAINLY to suggest and promote the idea that the "time slices" within the main iteration loop of PortBalWiz, which are at the core of the CPU-bottleneck issue that in turn limits future user application of that tool - can be REDUCED significantly in number (50-90+%) by using dynamic time slices. The actual rules for determining where the boundaries of those slices lie should IMHO have hooks so that users can use OVest Pro language (or even OScript) to define the breakpoints. But also, some reasonable default should be provided, so that "normal" PortBalWiz runs don't automatically utilize non-dynamic test-every-fixed-slice-because-we-can approach. [Edited by Jim Dean on 4/14/2014 10:34 AM] | ||
| Pete Taylor Member Posts: 28 Joined: 10/11/2012 Location: N Bradley, England User Profile |
I agree with your idea that the market should dictate to us how quickly we start to change things around, rather than the other way around. Especially in bear markets things often happen very quickly. I don't know if we are looking to get this sorted initially with OV pro - but it would be great to have a system which is almost looking out for signs of change, as we often don't see them(or don't admit to seeing them) when they happen ourselves. I looks like your research is very similar in nature to that of Van Tharp, he does a free monthly newsletter, where he gives his current view of the market type. Just to confuse us he has 5 market types, strong bear, bear, neutral, bull & strong bull - together with current volatility measurement. Would interested to hear your thoughts on these. If you are interested all his previous ones are available for free on the web. The last one done April 10th 2014 is on the following link thought that you may be interested. http://www.vantharp.com/Tharps-Thoughts/676_Apr_09_2014.html Personally with the right portfolios & strategies in place I don't feel we need to go into that much detail of guessing where the market is going, but just have a way of shortening the "time slices" when things may be changing as a wait of say a month may be too long. | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
I've long been a proponent of Van Tharp's books ("Trade Your Way to Position Sizing", and "Position Sizing"), and I read his newsletter regularly (some of his more recent "mystical" emphasis give me pause, though ;~). My work in many areas incorporates some of his general ideas, as well as those of Dr. Alex Elder ("Trading for a Living") ... but I've also added my own ideas, and refined theirs a considerable amount. I sent Ed a simple algorithm for position sizing that I hope will be implemented soon, along those lines. My hope is that when the "dynamic" time slices are implemented, the PortWizBal ("Wizard" plus "Balancing" = "Wiz-Bang" ;~) will permit users to select WEEKLY granularity, as long as some kind of dynamic rule is also provided, to keep the total number of slices in the selected analysis window to no more than 10-12/year ... that will provide for a more TIMELY refining process, but with no greater CPU burden than "plain" monthly slices. [Edited by Jim Dean on 4/14/2014 8:26 AM] | ||
| Mark Holstius Elite Posts: 744 Joined: 10/11/2012 Location: Sleepy Hollow, IL User Profile |
I threw this out there to stimulate thinking - but also to show what can be accomplished / uncovered once we can see data on a "grander" scale. The runs to generate my table can take 20 to 30 hours using Excel, so I'm really looking forward to what we might find once Ed and the staff give us the horsepower to do the calculations faster along with the capability to download the results. I know they're working hard on that, and I don't want to detract from that process. I suspect the discoveries will multiply (very profitably) with these new tools... Mark |
|
|
|
|
Administrator
Forum Moderator |
Registered User
Unregistered User |
 E-Mail this thread to a friend |
Toggle e-mail notification |
