Jim Dean Elite   Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA  User Profile | During the webinar, Ed asked me to write up an idea I'd asked about ... this relates to the "detailed" description he provided regardng how PortWiz will be operating. I titled the thread so that other suggestions that might improve PortWiz &/or PortBal performance could be posted. (CPU cycles required, or "value" of the results) 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. | |
