Ted
You can try this
MA1Length = optimize("MA1Length", 50, 50, 200, 1);
MA2Length = MA1Length + Optimize("MA2Variable", 1, 0, 100, 1);
...--- In [email protected], Ted Byers <r.ted.by...@...> wrote: > > 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 <howardba...@...> 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. > t...@... > CTO > Merchant Services Corp. > 350 Harry Walker Parkway North, Suite 8 > Newmarket, Ontario > L3Y 8L3 >
