Hi Howard, Thanks for this. I should probably have said I come from a mathematical/scientific background, looking at risk in both environmental and ecommerce systems. I have had to wrestle with situations where the simplest mathematical descriptions had several dozen state variables and substantially more parameters that had to be optimized. And in the course of this work, I had to extend the analysis to examine the structural stability of the resulting system (i.e. does the expected behaviour change significantly even if only minor changes in the parameter values occur). Needless to say, I had use exhaustive optimization routines only for teaching purposes; never in real world situations. And I have substantial experience making my numeric C++ code fast. ;-)
I have also routinely faced the 'curse of dimensionality', but that is not much of a problem WRT curve fitting as long as there is more than enough data to leave a large number of degrees of freedom. I know constrained optimization is far from trivial for real world systems. My question is related specifically to the extent that AmiBroker's optimization code supports more realistic constrained optimization. I am concerned, here, about whether or not AmiBroker will save me on the amount of time I will spend coding. In C++, I can write my fitness functions and constraint functions for the system parameters so that the cost of a call for excluded combinations of parameters amounts to no more than the cost of a function call. But the cost of writing that is the cost of a significant amount of my time. My junior colleagues haven't a hope of being able to write such code in a reasonable amount of time. Cheers Ted On Wed, Jan 6, 2010 at 4:54 PM, Howard B <[email protected]> wrote: > > > Hi Ted -- > > Yes, you can design a trading system in AmiBroker that recognizes what type > of a market it seems to be in, then issue trading signals based on the > market type and the system specific to it. > > Keep in mind the "curse of dimensionality" that will show up when you try > to put everything into a single afl. If you have two systems, each with > four optimizable parameter values, and a ninth parameter to decide which set > of four to use, you will be optimizing and walking forward all nine, even > though only five will be in use at any given time. If each parameter has > "only" 10 possible values, the 9 parameter runs will evaluate 9^10 > alternatives (using exhaustive searching), while the 5 parameter runs will > evaluate 5^10. > > Since there is no overlap between the two market types, there are a lot of > evaluations that will make no difference. That is, the value of the > objective function will be computed for each, but will be the same for > many. You might be better off writing two separate programs. One afl > program recognizes Market Type A, and selects the best logic and parameters > for that type; the other recognizes Market Type B, and selects the best > logic and parameters for that type. In terms of optimization runs, doing > everything at once costs 9^10 runs, while doing the two separately costs > 2*5^10 -- a factor of 5000. If doing the development for one of the > four-plus-one parameter systems takes one hour of computer time, doing the > two separately takes two hours, and doing both in a single nine parameter > afl takes 10000 hours -- over a year. Non-exhaustive optimization will help > a lot, but not completely remove the curse. (I know -- times are not > strictly proportional.) > > Thanks, > Howard > > > > -- R.E.(Ted) Byers, Ph.D.,Ed.D. [email protected] CTO Merchant Services Corp. 350 Harry Walker Parkway North, Suite 8 Newmarket, Ontario L3Y 8L3
