Jim Dean![]() Elite ![]() ![]() ![]() Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA ![]() | Wow Mark! You don't do anything in a slapdash kinda way, do ya! I had to read thru that a couple of times to get it - really an innovative way of approaching the age old problem of "which indicator is best". 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] |