Jim Dean![]() Elite ![]() ![]() ![]() Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA ![]() | Great suggestion, Pete - another very simple approach that might do the trick, to cut the CapU time by a major fraction. My bias is to define at least three states rather than whipsawing between two, and to try to discern between three general trend states in conjunction with three general volatility states. Click here for a long thread with some general work that I've done on this. VIX is a good building block to fold in to the process - and as you suggest, might be sufficient, by itself, or maybe with a little math on top of it to prevent whipsaws. 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] |