I will try to describe the beginning of the design process I'm working on in a series of 5 steps. This is a work-in-progress, but I have already spent many many hours refining it to this point. My hope is that other n00bs will find this useful, perhaps a launching point to great new ideas that can be shared.
My objective is to build a legion of tradebots that I, the human trader, will manage. Each tradebot will have its own broker account and be assigned a part of the trading stake. Like any good manager, my job as human will be to watch over my bots and make sure they are performing within their "acceptable spec". If they fall out of spec, I plan to have other contender bots waiting in line to step-in. The number of bots running at any given time is not defined, but is limited by the total size of my trading stake.
With this basic understanding of my objectives, I am interested in rapid development of new bots. To achieve this, I have created a basic set of standards and tools that each bot follows. I believe it's possible that forcing a bot to fit into such an infrastructure could be limiting in some ways, and that leaves a lot of room for efficiency improvements. However my goal will always be to apply such improvements to the infrastructure so that it can be reused in future bots. With each iteration of new bots I've been able to continually improve the toolbox a little more, and I expect this would continue with no limits. As the number of available tradebots exceeds the room in my legion (ie, number of funded broker accounts), I would simply decommission the lesser-performing bots and replace with the best-of-breed contenders.
-----------------------------------------------------------------
STEP 1: Identify "the edge"When you set out to create a bot, it can be overwhelming. Especially if you are new to scripting or unfamiliar with how Zorro works. You probably have some idea of how your system would trade, but perhaps unsure the best way to translate those mechanical steps into a tradebot. In this first step of design, you will assemble those simple trading rules and show that it is (at least marginally) profitable in a backtest.
I started with a simple trend-following logic that is found in a snippet on the manual page for "optimize"
here. The goal of Step 1 is to
identify a marginally profitable edge which is nicely achieved by the example on this page. However, the example code does not explicitly define other personalities of the tradebot, such as how frequently it implements the edge. I was looking to build a hyper-tradebot on a small timeframe of about 15 minutes. So here are the details of Step 1a:
Step 1a: Goal: identify marginally-profitable edgeNo WFO; No oversample; Simple Stop; Std entryI keep track of these design steps in a spreadsheet, and I use the blue notation above to "remind myself" of important restrictions in each step of the process. It's extremely important that the process be both objective and consistent. I don't ever want to find myself in the position of having created something successful, yet unsure how exactly I arrived at that point.
At this step: No WFO means that this will be a straight backtest only. Oversampling (NumSampleCycles) is not set. Simple stop means that, essentially, I have not yet defined an appropriate stop logic. In its place I use only a generic dynamic stop (see below). Std entry means that I also use a very generic entry method with no special bells or whistles yet.
function run()
{
set(PARAMETERS);
StartDate = 20080101;
EndDate = 20130531;
BarPeriod = 15;
//edge trading logic
var TimeCycle = optimize(75,50,100,1,0);
var TimeFactor = optimize(3,1,5,0.2,0);
Stop = BarPeriod*PIP; //simple stop level
LookBack = 100*5;
vars Price = series(price(0));
vars MA1 = series(SMA(Price,TimeCycle));
vars MA2 = series(SMA(Price,TimeCycle*TimeFactor));
if(crossOver(MA1,MA2))
enterLong(); //standard entry
else if(crossUnder(MA1,MA2))
enterShort(); //standard entry
}
With only minor tweaking of the example code, the Train+Test can already yield
AR 44% which qualifies this edge as having potential at this timeframe.
Step 1b: optimize the BarPeriodI want the BarPeriod small (this is to be a hyper-bot, remember?) but I want Zorro to tell me which BarPeriod is really best. So I tell Zorro to scan all nearby small timeframes. I want to manually review the optimization chart for this step, so I need to hardcode the TimeCycle and TimeFactor variables, which I'll do temporarily by getting the found-best values out of the Data/script.par file. Training then with only 1 optimized parameter (the BarPeriod) will cause Zorro to produce the opt chart that I want. I can see clearly from this chart that BarPeriod 15 is indeed the best-of-breed at this small frequency.
function run()
{
set(PARAMETERS);
StartDate = 20080101;
EndDate = 20130531;
BarPeriod = optimize(15,5,20,1);
//edge trading logic
var TimeCycle = 61; //optimize(75,50,100,1,0);
var TimeFactor = 2.8; //optimize(3,1,5,0.2,0);
Stop = BarPeriod*PIP; //simple stop level
LookBack = 100*5;
vars Price = series(price(0));
vars MA1 = series(SMA(Price,TimeCycle));
vars MA2 = series(SMA(Price,TimeCycle*TimeFactor));
if(crossOver(MA1,MA2))
enterLong(); //standard entry
else if(crossUnder(MA1,MA2))
enterShort(); //standard entry
}
(Coming next...)Step 1c: Goal: identify optimizable parametersStep 1dStep 1eStep 1f: Goal: identify modifiers that work wellStep 1g
