Automated Trading & Backtesting Course - Part 2: System Development

This is the second part of the automated trading course, which will deal with how to develop a profitable strategy. No further programming knowledge is required when you did the first part of this course. It's here: http://www.forexfactory.com/showthread.php?t=388887

This second part will cover writing basic trading strategies, optimizing, walk forward analysis, portfolio strategies, and money management. It uses some new trading algorithms such as frequency filters. To avoid misunderstandings: It's not a course about technical analysis. I won't explain here moving averages or the like. It's just about how to develop and backtest a strategy based on a trading idea that you already have.

The goal is developing a robust portfolio strategy with a stable return. You can see the out-of-sample equity curve of such a portfolio system here, although it is not the same strategy as developed in the course:

http://zorro-trader.com/manual/images/z2perf2.png

For the course you'll need a free program for running the script examples and testing the strategies. It's called "Zorro" and you can download it from zorro-trader.com. Please also keep two things in mind:

► All strategies presented in this thread are meant for educational purposes. They are all profitable, but designed for simplicity, not for maximum profit or robustness. For really trading such a strategy, you would normally add entry filter rules for filtering out unprofitable trades. How to find and generate such rules with machine learning algorithms, such as Zorro's perceptron or decision tree, might be covered in a future third part of the course. For really trading a strategy you normally also use a more sophisticated exit algorithm, realized with a trade management function. But that's also stuff for a future part and we'll keep it simple in this part of the course.

► I will post some backtest results here, but they can be slightly different to the results you'll get when testing the scripts yourself. That's because the simulated spread, commission, and rollover parameters can be different and the backtest periods are also different. You could prevent this by setting Spread and other broker dependent parameters to a fixed value in the script, and use fixed periods for simulation and test, but keeping them up to date with the market gives a more realistic result.

Let's start. The point of trading is knowing the moment when it's good to buy, good to sell, or good to do nothing. Any trade system uses market inefficiencies - deviations of the price curves from random data - for predicting future prices and finding the right buying and selling points.

The most obvious way to make profits is going with the trend. Let's have a little stage play in which trader Bob tries to explain his trade strategy to programmer Alice. Bob has just hired her to automatize his system:

Bob: I go with the trend. I buy long when prices start going up and I go short when they start going down.
Alice: And this works?
Bob: Sometimes. Depends on the market.
Alice: So you just buy long when today's price bar is higher than the bars of the previous days?
Bob: Nah, one higher price bar alone won't do. Prices wiggle a lot. Often the candles are all over the place. I look for the long term trend, like the trend of the last two months. I do that with a moving average.
Alice: Good. That shouldn't be a problem to automatize.
Bob: Well, actually there is a problem. You see, a two month moving average lags at least one month behind the price. Often the trend is already over when the average finally bends up or down. You need to sort of look ahead of the moving average curve, if you get my meaning.
Alice: So you want to know when a two months trend changes, but you need to know it in far less time than two months?
Bob: You got it.
Alice: I could use a lowpass filter for getting the trend curve. Second order lowpass filters have almost no lag. Will that be ok for you?
Bob: I dunno what a second order lowpass filter is. But I trust you.
Alice: Good. So I buy when the trend curve changes its direction? For instance, when it starts to move up from a valley, or down from a peak?
Bob: You got it.
Alice: How do you exit trades?
Bob: When it's the right time. Depends on the market.
Alice: I can exit a long position when entering a short one and vice versa. Does this make sense?
Bob: Yeah, that's what I normally do when I'm not stopped out earlier.
Alice: Stopped out?
Bob: Sure. A trade must be stopped when it's losing too much. We need a stop loss. Or do you want my whole account wiped from some bad trade?
Alice: Certainly not before I'm paid. At which price do you place the stop loss?
Bob: Not too far and not too tight. I don't want to lose too much, but I also don't want my trades stopped out all the time.
Alice: So let me guess: it depends on the market?
Bob: You got it.

Following the conversation, Alice wrote this trade strategy script for Bob (fee: $5,000):


From the first part of the course you might recognize some familar structures, such as the if statement, and some lines that look similar, but not quite like variable declarations. Tomorrow we'll go thoroughly over this script, analyze what it does line by line, and then look in detail into the behavior and performance of this strategy.

We're now going to analyze the code. At first, we can see that the function is now named "run" and not "main". "run" is also a special function name, but while a main function runs only once, a run function is called after every bar with the period and asset selected with the scrollbars. By default, the bar period is 60 minutes. So this function runs once per hour when Zorro trades.

At the begin we notice two strange lines that look similar to var definitions from the first part of the course:

var *Price = series(price());
var *Trend = series(LowPass(Price,1000));

However unlike var definitions, they have an asterisk '*' before the name, and are set to the return value of a series() function call. We define not a single variable here, but a whole series. (C++ programmers might notice that we in fact define a pointer, but that needs not bother us now). A series is a variable with a history - the series begins with the current variable value, then comes the value the variable had one bar before, then the value from two bars before and so on. This is mostly used for price curves and their derivatives. For instance, we could use a series to take the current price of an asset, compare it with the price from 1 bar before, and do some other things dependent on past prices. The series is the ideal construct for such price calculations.

The current value of a series can be used by adding a [0] to the series name; for the value from one bar before add a [1], for two bars before add a [2] and so on. So, in Alice's code Price[0] would be the current value of the Price series, and Price[1] the value from 1 hour ago. Many trade platform languages - for instance, EasyLanguage - support series this way; usually indicator, statistics, and financial functions all use series instead of single variables. We'll encounter series very often in trade scripts and will become familiar with them.

The series() function can be used to convert a single variable to a series. The variable or value for filling the series is normally passed to that function. However, we're not using a variable here, but the return value of a function call. var *Price = series(price()); means: define a var series with the name "Price" and fill it with the return value of the price() function. We've learned in the last programming lesson how to 'nest' function calls this way, passing the return values of functions as parameters to other functions.

The price() function returns the mean price of the selected asset at the current bar. There are also priceOpen(), priceClose(), priceHigh() and priceLow() functions that return the open, close, maximum and minimum price of the bar; however, the mean price is usually the best for trend trading strategies. It's averaged over all prices inside the bar and thus generates a smoother price curve.

var *Trend = series(LowPass(Price,1000));

The next line defines a series named "Trend" and fills it with the return value from the LowPass function. As you probably guessed, this function is the second order lowpass filter. Its parameters are the previously defined Price series and a cutoff value, which Alice has set to 1000 bars. 1000 bars are about 2 months (1 week = 24*5 = 120 hours). Thus the lowpass filter attenuates all the wiggles and jaggies of the Price series that are shorter than 2 months, but it does not affect the trend or long-term cycles above two months. It has a similar smoothing effect as a Moving Average function, but has the advantages of a better reproduction of the price curve and less lag. This means the return value of a lowpass filter function isn't as delayed as the return value of a Moving Average function that is normally used for trend trading. The script can react faster on price changes, and thus generate better profit.

Please ask if something so far was unclear.

The next line in Alice's system places a stop loss limit:

Stop = 2*ATR(100);

Stop is a predefined variable that Zorro knows already, so we don't have to define it. It's the maximum allowed loss of the trade; the position is sold immediately when it lost more than the given value. The limit here is given by 2*ATR(100). The ATR function is a standard indicator. It returns the Average True Range - meaning the average height of a candle - within a certain number of bars, here the last 100 bars. So the position is sold when the loss exceeds the size of two candles. By setting Stop not at a fixed value, but at a value dependent on the fluctuation of the price, Alice adapts the stop loss to the market situation. When the price fluctuates a lot, higher losses are allowed. Otherwise trades would be stopped out too early when the price jumps down just for a moment.

A stop loss should be used in all trade strategies. It not only limits losses, it also allows to calculate the risk per trade for a more accurate performance analysis.

The next lines are the core of Alice's strategy:


The valley function is a boolean function; it returns either true or false. It returns true when the series just had a downwards peak. The peak function returns true when it just had an upwards peak. When the if(..) condition becomes true, a long or short trade with the selected asset is entered with a enterLong or enterShort command. If a trade was already open in the opposite direction, it is automatically closed. Note how we combined the else of the first if with a second if; the second if() statement is only executed when the first one was not.

Let's have a look into an example trade triggered by this command:

http://zorro-trader.com/manual/images/work4_detail.png

The red line in the chart above is the Trend series. You can see that it has a peak at the end of September 2008, so the peak(Trend) function returned true and the enterShort function was called. The tiny green dot is the moment where a short trade was entered. The Trend series continues downwards all the way until November 23, when a valley was reached. A long trade (not shown in this chart) was now entered and the short trade was automatically closed. The green line connects the entry and exit points of the trade. It was open almost 2 months, and made a profit of about 13 cents per unit, or 1300 pips.

Tomorrow we'll learn how to backtest such a strategy and how to judge its profitability.

Obviously, a strategy is worthless as long as you don't know how it will perform. For this you need to run a backtest over at least 4 years. Start up Zorro, select the [Workshop4] script and the [EUR/USD] asset, leave the [Period] slider at 60 minutes, then click [Test]:

http://zorro-trader.com/manual/images/work4_11.png

You might get a different result when testing this strategy in a different time period or when your broker has different spread, rollover costs, commission, or slippage. By default, the simulation runs over the last 5 years, i.e. from 2008 until 2012. The strategy achieves an annual profit of ~1200 pips, equivalent to about 60% annual return on capital - that's the average profit per year divided by the sum of maximum drawdown and maximum margin. The average monthly income (MI in the window) is 8 $. That's quite modest, but Zorro simulated a microlot account and needs only 160 $ capital for keeping this strategy at a safe distance from a margin call. So you have 5% return on capital per month. By the way, the '$' sign in Zorro's messages does not necessarily mean US-Dollar, it stands for the account currency.

We can experiment a little by replacing the lowpass filter with other methods. When replaced with an traditional Exponential Moving Average (EMA) indicator, we had to use a shorter time period of 250 bars for getting about the same lag as a lowpass filter with 1000 bars. The second line in the code would then look like this:

var *Trend = series(EMA(Price,250));

and the system would become unprofitable, as an EMA with this short time period is too "jittery" for reliable peak and valley signals. Using lowpass filters instead of moving averages often improves the strategy performance, and can sometimes even make the difference between a winning and a losing system.

Let's look further into the performance of our first automated strategy. Although 60% look better than the usual 4% of a savings account, Alice is not too excited about the result. The low Sharpe ratio (SR) tells her that this result comes at a risk. The Sharpe ratio is the mean annual profit divided by its standard deviation. Sharpe ratios below 1 indicate that the gains fluctuate a lot - there might be years when the strategy achieves a lower profit, or even a loss. This is confirmed by the profit curve that Alice gets by clicking [Result]:

http://zorro-trader.com/manual/images/work4_chart.png

In the image that pops up in the chart viewer, you can see a blue area, a black curve, and some green lines and red dots attached to the curve. The black curve is the price of the selected asset - the EUR/USD, i.e. the price of 1 EUR in US$. The price scale is on the left side of the chart. The green and red dots are winning and losing trades. The green lines connect the entry and exit point of a winning trade. You can see immediately that there are far more red than green dots - 81% of the trades are lost, only 19% are won. However, the long-term trades all have green lines. So we have a lot of small losses, but several large wins. This is the typical result of a trend following strategy.

The most interesting part of the chart is the blue curve that indicates our equity. We can see that it's going up from zero in 2008 to $500 in 2012. This is a good thing. However the equity curve is quite shaky. The winning years are 2008 and 2010; in the other years we had a loss or a tie. This shaky behavior is reflected in the low Sharpe ratio (SR) and the high Ulcer Index (UI). It would require strong nerves to trade such a strategy; there are long periods during which the strategy is losing money. Can Alice come up with some idea to improve the strategy a little?

Alice had noticed that the losing trades are all clustered around sideways price movements, while the wins occur during long up or down trending periods. This effect can be used for filtering trades - suppressing trades as long as some indicator suggests that the market is moving sideways.

For simplicity's sake, Alice wants to use the Trend series itself not only for a trade signal, but also for a trade filter. In a non trending market the series would generate many trade signals close together. So the additional filter condition shall be: Don't trade when another trade signal happened within the last 4 bars. Alice could use a static counter variable for counting the trade signals, but a more elegant way is to just record them in a series. The code now looks like this:


The method of checking if a certain event happened within the last n bars is often used in trade systems, and it makes sense to look into that more closely. We'll do that tomorrow.

Alice had defined a new series for storing the trade signals:

var *Signals = series(0);

This series has the value 0 unless set otherwise. This happens when a peak or valley is encountered:

if(valley(Trend)) {
...
Signals[0] = 1;
} else if(peak(Trend)) {
...
Signals[0] = 1;
} else
Signals[0] = 0;

The current value of the Signals series - Signals[0] - is set to 1 when the Trend curve has either a valley or a peak, and to 0 otherwise. Now Alice can check the history of the series within the last 4 bars, using the Sum indicator:

if(Sum(Signals,4) == 0)
enterLong();

The Sum indicator just returns the sum of the series over the given time period. The sum is normally 0, unless Signals[0] was set to 1 anytime within the last 4 bars. Then the sum is the number of the trade signals during that time period. The if() condition ensures that a trade is only entered when the sum is 0.

This is the equity curve of the improved strategy:

http://zorro-trader.com/manual/images/work4_chart2.png

The annual return is now over 70% and all performance parameters - profit factor, Sharpe ratio, ulcer index - have improved. But it's not yet perfect: several previously profitable trades have now been also filtered away. Filtering is often a compromise between improvement and worsening. Anyway, Alice thinks that this strategy is now good enough for that lousy $5,000 programming fee, and Bob got what he wanted. We'll learn in the next days how to improve strategies further.

If you want to check the trades of this strategy in detail, add the following line to the begin of the script:

set(LOGFILE);

LOGFILE is a flag - something like a "switch" that can be on or off. Such switches are turned on with the set() function. If the switch is on, the next click on [Test] stores a log of all events in the Log subfolder. Open LogWorkshop4_EURUSDtest.log with the script editor or any other plain text editor. It begins like this:


The first short trade is entered after bar number 147, starting January 10 10:00 am. Zorro bought 1 lot EUR/USD at a price of $1.4676. The trade risk was about $6, determined by the stop loss distance (due to slippage the risk can be estimated only). Two bars later the short trade was closed at a loss of 59 cents, the position was reversed, and a long trade was opened at a price of $1.4682. The detailed meaning of the messages is listed in the Zorro manual under "Trading".

You can see in the log that most trades are lost. Zorro seems to deliberately enter trades in the wrong direction - trading at random would only lose about 50% of them, not 80%. But there's a method behind this apparently mad trading. The algorithm wants a favorable position when a long-term trend begins, and then keeps the position for a long time. That's why it wins in the long run, despite losing most trades.

----------------------

What have we learned so far?

* A strategy script contains a run function that is called once per bar.

* A series is a variable with a history.

* A lowpass filter removes the jaggies from a price curve without much lag penalty. It is superior to traditional moving averages.

* The valley and peak functions can be used to buy or sell at the turning points of a curve.

* A stop loss limits the trade risk.

* Filtering trades often improves the strategy performance.

* Use the LOGFILE switch for checking the strategy behavior in detail.

In the next days we'll learn how to optimize strategies and adapt them to different markets.

Bob got a new trade idea:

Bob: Last month I ran into Warren Buffett and asked him for a trading advice. That's what he said: 'Be greedy when others are fearful'.
Alice: Interesting. And what does it mean?
Bob: He didn't tell, but went away. But I think he wants me to go against the trend.
Alice: Isn't that just the opposite of your last strategy?
Bob: You got it. I need you to automatize this. I now buy long when prices moved down very much, and go short when they moved up very much.
Alice: How much is very much?
Bob: Depends on the market.
Alice: I should have known.
Bob: Well, prices often move up and down in cycles. Problem is, cycles are sometimes not easy to see in the price curve. You must find the main price cycle and check if the price comes close to its top or bottom. Then you know the right moment to buy or sell.
Alice: I can use a frequency analysis function to find the dominant period of the price cycle.
Bob: If you say so.
Alice: Then I only need to find the top and bottom. I use the dominant period to control a highpass filter. This will cut off the trend and all cycles below the dominant period and give me a clean cycle curve.
Bob: Hmm.
Alice: For finding how close the cycle is to its peaks, I must normalize the curve. For instance with a Fisher transformation. This has the advantage that the curve gets a Gaussian distribution. There are less extrema, and they are relatively sharp and well defined, so we won't get too many false signals.
Bob: I have no idea what you're talking about. But when it's sharp and well defined, I like it.
Alice: Of course it's more complicated than trend trading. This comes at a higher fee.
Bob: I like that less.
Alice: I can run a Walk Forward Optimization as an extra.
Bob: Huh? Will that get me more profit?
Alice: Not necessarily. But it will make your profit more certain. So that you can afford me.


This is the first version of Alice's counter trend trading script (fee: $12,000):


This system looks somehow more complex than the previous simple trend trading system. Tomorrow we'll go through the code and analyze it.

Counter trend trading is affected by market cycles and more sensitive to the bar period than trend trading. Bob has told Alice that bar periods that are in sync with the worldwide markets - such as 4 or 8 hours - are especially profitable with this type of trading. Therefore she has set the bar period to a fixed value of 4 hours, or 240 minutes:

BarPeriod = 240;

The counter trend trade rules are contained in the following lines that calculate the buy/sell signal. The first line sets up a price series just as in the trend trading strategy. The next one calculates the dominant period:

var *Price = series(price());
var *DomPeriod = series(DominantPeriod(Price, 30));

A price curve is often a superposition of weekly, bi-weekly or monthly trading cycles, and the dominant period is the most significant cycle in the curve. If prices would oscillate up and down every two weeks, the dominant period would be 60 - that's the length of two weeks, resp. 10 trade days, counted in 4-hour-bars. Alice uses the DominantPeriod() analysis function with a cutoff period of 30 bars for finding the main price oscillation cycle in the range below 100 bars. The result DomPeriod is a series of dominant periods.

var LowPeriod = LowPass(DomPeriod, 500);

Because the dominant period fluctuates a lot, the next line passes the series through a lowpass filter, just like the price curve in the trend trading strategy. The result is stored in the variable (not a series, thus no '*') LowPeriod that is the lowpass filtered dominant period of the current price curve.

var *HP = series(HighPass(Price, LowPeriod));

In the next line, a highpass filter is fed with the price curve and its cutoff frequency is set to the dominant period. This removes the trend and all cycles that are lower than the dominant period from the price curve. The HighPass() function is similar to the LowPass function, it just does the opposite, and leaves only high frequencies, i.e. short cycles, in the price curve. The result is a modified price curve that consists mostly of the dominant cycle. It's stored in a new series named HP (for HighPass).

var *Signal = series(Fisher(HP, 500));

The values of the HP price curve are all over the place; for generating a trade signal they must be normalized - meaning they are 'compressed' in a defined range so that they can be compared with a threshold. In traditional technical analysis, an indicator wrongly called "Stochastic" is used for normalizing a curve. Alice prefers the Fisher Transformation. This is an operation that transforms an arbitrary curve into a Gaussian distribution - that's the famous 'bell curve' distribution where most values are in the center and only few values are outside the +1...-1 range. This transformation is done with the Fisher() function. It converts the HP series into the Gaussian distributed Signal series, using the last 500 bars for the normalization.

var Threshold = 1.0;

This line defines a new variable Threshold with a value of 1.0. Alice's intention is to let any Signal value that leaves the +1.0 ... -1.0 range trigger a trade.

This happens in the following part of the code. Before we can start trading, Alice places a stop loss at an adaptive distance from the price, just as in the trend trading script. The ATR function is again used to determine the stop loss distance at the average height of 4 candles:

Stop = 4*ATR(100);

Additionally to the stop loss, Alice has also placed a trail limit 4 average candles away from the current price:

Trail = 4*ATR(100);

If the trade now goes in favorable direction by more than 4 average candles, the stop loss will follow the price at a distance of 8 candles. This ensures that all trades that reach an 8 candle profit are guaranteed to end with a win, regardless how the price further behaves. Trailing often - not always - improves the profit of a strategy, but is almost always better than placing a profit target.

if(crossUnder(Signal, -Threshold))
enterLong();
else if(crossOver(Signal, Threshold))
enterShort();

When the Signal curve cosses the negative threshold from above - meaning when Signal falls below -1 - the price is supposedly at the bottom of the dominant cycle, so we expect the price to rise and buy long. When the threshold is crossed from below - meaning Signal rises above 1 - the price is at a peak and we buy short. This is just the opposite of what we did in trend trading. For identifying the threshold crossing we're using the crossOver() and crossUnder() functions.

- Obviously, these trade rules are somewhat more complicated than the simple lowpass function of the previous script. So Alice needs to see how the various series look, for checking if everything works as supposed. This happens in the last lines of the script that we'll go through tomorrow.

The following lines at the end of the script are responsible for displaying the signal curves in the chart:

plot("DominantPeriod", LowPeriod, NEW, BLUE);

generates a plot of the LowPeriod variable in a NEW chart window with color BLUE. We can use the plot function to plot either in the main chart with the price and equity curve, or below the main chart in a new window. The Signal curve and the upper and lower Threshold are plotted in another new chart window:

plot("Signal", Signal[0], NEW, RED);
plot("Threshold1", Threshold, 0, BLACK);
plot("Threshold2", -Threshold, 0, BLACK);

The first statement plots the Signal[0] value as a red curve (as we remember, adding a [0] to a series name gives its most recent value). The next two statements plot the positive and negative Threshold with two black lines in the same chart window. Note that the plot function always expects a value, not a series - that's why we needed to add the [0] to the Signal name.

PlotWidth = 1000;
PlotHeight1 = 300;

This just sets the width and height of the chart window. Below is the resulting chart. Load the script workshop5_1 in Zorro and make sure that EUR/USD is selected. Click [Test], then click [Result]:

http://zorro-trader.com/manual/images/work5_1.png

The blue curve in the middle window is the plot of LowPeriod. It moves mostly between 30 and 40 bars, corresponding to a 5..7 days dominant cycle. The bottom window shows the Signal series. The black lines are the thresholds that trigger buy and sell signals when Signal crosses over or under them. Plotting variables and series in the chart greatly helps to understand and improve the trade rules. For examining a part of the chart in details, the StartDate and NumDays variables can be used to 'zoom into' a part of the chart.

We can see that the highpass filter system generates more than 100% annual return. This is already better than the simple trend trading script; still, Alice intends to do more for her fee. Tomorrow we'll learn how a system can be trained for increasing its 'robustness' and generating more consistent returns.

Today we'll learn how to make a system more robust with training. Training means that strategy parameters are optimized - modified in small steps until the strategy returns stable profits with minimum variance. Which parameters are optimized in which way is determined in the script; optimization is thus a part of the strategy.

Alice has added some commands to the strategy for parameter optimization (select Workshop5_2):


Parameter optimization requires some additional settings at the begin of the script:

set(PARAMETERS);
BarPeriod = 240;
LookBack = 500;

PARAMETERS is a flag - similar to the LOGFILE flag that we know from the last workshop - that tells Zorro to generate and use optimized parameters. LookBack must be set to the 'worst case' lookback time of the strategy. The lookback time is required by the strategy for calculating its initial values before it can start trading. It's usually identical to the maximum time period of functions such as HighPass() or Fisher(). If the lookback time depends on an optimized parameter, Zorro can not know it in advance; so we should make it a habit to set it directly through the LookBack variable when we optimize a strategy. In this case we set it at 500 bars to be on the safe side.

The signal calculation algorithm now also looks a little different:

var Threshold = optimize(1, 0.5,2,0.1);
Stop = optimize(4, 2, 8) * ATR(100);

Threshold and Stop are now set from the return values of optimize function calls. It is also important now that the line with the Threshold setting comes before the line with the Stop setting in the code. More important parameters should be optimized first, and the most important is Threshold which determines the sensitivity of the strategy and has the largest influence on its profit.

For setting Threshold, optimize is called with 4 numbers. The first is the parameter default value, which is 1 - just the value that Threshold had before. The next two numbers, 0.5 and 2, are the parameter range, i.e. the lower and upper limit of the Threshold variable. The 4th number, which is optional, is the step value to increase the parameter for every optimization run. So Threshold can now have any value from 0.5 to 2 in steps of 0.1. During the optimization process, Zorro will try to find the most robust value within this range.

Alice has also optimized the stop loss distance. The default value is again 4 average candles. Note that the optimize function is only called with 3 parameters here, the step parameter is omitted - in this case Zorro just increases the value by 10% for every optimization step. We only needed to give the step value for the threshold that should be increased in equal steps.

Theoretically, there could be even more parameters to optimize - for instance the DominantPeriod cutoff value, or the number of bars for the ATR function, or the Trail distance. But the more parameters we have, and the larger their range is, the higher is the danger of overfitting the strategy. Overfitted strategies perform well in the simulation, but poor in real trading. Therefore only few essential parameters should be optimized, and only within reasonable parameter ranges.

Tomorrow we'll check how training affects the performance and equity curve of the strategy.

For training the strategy, click [Train] and observe what the optimize calls do. During the training phase, which can take about one minute depending on the PC speed, you'll see some charts pop up, like this:

http://zorro-trader.com/manual/images/work5_2_p1.png
Parameter 1 (Threshold)

http://zorro-trader.com/manual/images/work5_2_p3.png
Parameter 2 (Stop factor)

The parameter charts show how the parameter values affect the performance of the strategy. The red bars are the return ratio of the training period - that's basically the total win divided by the total loss, multiplied by a correction factor for the error term. The dark blue bars are the number of losing trades and the light blue bars are the number of winning trades. We can see that Threshold has a maximum at 1.10; the Stop factor - the second parameter - has a maximum at about 6. We can also see that a distant stop, although it increases the risk, also increases the number of profitable trades, the 'accuracy' of the strategy.

The optimized parameters are stored in the file Data/Workshop5_2_EURUSD.par. Different parameter sets could be generated for other assets. A click on [Test], then on [Result] displays the equity chart of the optimized strategy:

http://zorro-trader.com/manual/images/work5_2.png

We can see that training has improved the script. The annual return now exceeds 150%, meaning that the invested capital more than doubles every year. The new Sharpe Ratio is above 1, meaning that this strategy is really tradable. Or is it?

Well, in fact it's too good to be true. If Alice would deliver the system with this test result, she would have made a severe mistake and Bob would not get as rich as expected - if at all. What's the problem?

We'll look into that tomorrow.

Alice has used the price data from the last 5 years for optimizing the parameters, and has used the same price data for testing the result! This always generates a too optimistic result due to curve fitting bias. It also has a second problem. In 5 years, markets change and trading strategies can become unprofitable. It is not recommended to trade an optimized strategy unchanged for 5 years. Normally the strategy parameters should be re-optimized in regular intervals for adapting them to the current market situation. Zorro can do that automatically while life trading, but how can we simulate this in a test and get some realistic prediction of the real trading behavior?

The answer is Walk-Forward Optimization. Contrary to its name, it's not merely an optimization. It's also a analysis method that tests not only the strategy algorithm, but also its parameter ranges and optimization settings. If a strategy fails in a walk forward analysis, it will also fail in real trading, even if it collected huge profits in a backtest. For this reason, walk forward optimization (WFO) is the most important process when developing a strategy or EA - and this lesson today is the most important one for learning strategy development.

WFO requires only adding two lines at the begin of the script (Workshop5_3):

NumWFOCycles = 10;
NumBarCycles = 3;

The first line activates WFO with a data frame that is shifted in 10 cycles over the simulation period. The frame consists of a training period and a subsequent test, as in the figure below:

http://zorro-trader.com/manual/images/work5_table.png

The training period generates the parameters that are then tested in the subsequent test period. This makes sure that every test uses "unseen" price data that was not used for optimizing its parameters - just as it would happen in real trading. The data frame is then shifted over the simulation period for verifiying how the strategy would fare when started at different times.

However, there's a problem. Obviously WFO uses less price data than an optimization over the full simulation period. The less trades are simulated in the optimization and test process, the less accurate is the result. For getting more trades per WFO cycle, Alice could use a longer cycle period. Problem is that the markets change over time, so a price curve from 2009 likely requires different strategy parameters than a price curve from 2011. When using more than about one or two year's price data for a WFO cycle, the data covers too different market periods, which often makes optimization ineffective. The result is then worse and not better.

Therefore, the challenge is not using more data, but getting more trades out of the same data. Because historic price data is available in a much higher resolution than the bar period, a method called 'Oversampling' can be used for increasing the number of trades. The simulation is repeated several times. Every time the bars are resampled with a different offset into the price data. This generates a set of curves with slightly different bars that trigger different trades in every curve, while at the same time maintaining the trends, periodic behavior, and other characteristics of the original price curve.

For this Alice has set the NumBarCycles variable to 3. This runs the simulation three times with resampled bars, and calculates the performance and equity curve from the average of the three simulation cycles. Oversampling can remarkably increase the quality of the optimization process, as well as the accuracy of the test result. Of course, oversampling has a limit - we're still using the original prices after all, only the bars are built in a different way. The method does not much improve strategies that are based on very smoothed trend curves, such as for the crossing of two very long-period moving averages. But it works well for strategies that use the high-frequency part of a price curve. And it is another test for the strategy: if it fails with oversampling, it is likely overfitted to the bars of the original price curve.

After loading the Workshop5_3 script, click [Train]. Training now takes a few minutes because a full optimization is performed for every cycle, and the process is repeated 3 times with oversampling. The optimized parameters are now stored in a different parameter file for every WFO cycle. They are used when you click [Test] after the optimization process.

Tomorrow we'll check out what WFO has done with Alice's strategy. Please ask here is something was unclear or bad explained - this lesson was really important because WFO is the key to successful system development.

This is the performance of the WFO-trained strategy - again, depending on the current price data your result might look slightly different:

http://zorro-trader.com/manual/images/work5_31.png

Click [Result] for getting the chart below:

http://zorro-trader.com/manual/images/work5_4.png

We can see that the test now only covers 3 years; 2008 and 2009 are used up for the lookback and training periods. Although the equity curve does not look smooth, the strategy stays profitable with walk forward analysis and oversampling, which constitutes a hard 'stress test' for strategies. Alice concludes that it's worth her $12000 fee...

When life trading this strategy, it must now be regularly re-trained and adapted to the current market situation, just as in the WFO process. For this, Alice has added the following lines to the script:


ReTrain is nonzero when the [Train] button is clicked during life trading. UpdateDays is the time period for loading new price data from the broker's server; in this case new price data is loaded when the price data to be used for optimization is older than 30 days. SelectWFO tells Zorro not to optimize the whole simulation period, but only a certain WFO cycle; in this case, the last cycle that contains the new price data.

Clicking [Train] every couple of months will continue the WFO process during trading, and makes the strategy independent of external parameter settings - we have essentially a 'parameter-free' strategy. Can we really expect the projected annual return and average monthly income when we let Zorro trade it this way? Maybe in the long run, but we'll have have long periods, as in 2012, with no profit. Tomorrow we'll learn how to make strategy returns more steady and reliable so that Bob can really derive a regular income from them.

What have we learned so far?

► The DominantPeriod function returns the main cycle of the price curve. It can be used to control filters or indicators.

► The HighPass filter removes the trend from a price curve.

► The Fisher transform compresses a curve to a Gaussian distributed range.

► The plot function displays the curves of signals and indicators.

► The crossOver and crossUnder functions detect the crossing of a curve with a threshold or with another curve.

► Optimize parameters for for making a strategy more robust.

► Walk Forward Optimization simulates trading under realistic conditions.

► Oversampling improves the optimizing quality and and the test accuracy.

► WFO trained strategies should be re-trained in regular intervals.

Tomorrow we'll start with portfolio trading. You'll also learn that money management is very different to the usual "trade only 1% of your account" rule.

Bob: I got it! This is it!
Alice: Bob! Why are you running naked through the streets?
Bob: Huh? Oh, I was just sitting in my bathtub when I suddenly got this brilliant idea. I need you to program it immediately. This will solve all my trading problems!
Alice: Problems? I thought you were already getting rich by automated trading?
Bob: It started well, but then went all wrong. You know, from all the systems you programmed for me, the counter trend system worked best.
Alice: I figured that.
Bob: And from all assets, I found it had the most profit with the EUR/USD. So I invested all my money in that system trading with EUR/USD.
Alice: Oh no!
Bob: Yes! And it worked like a champ! My account went up from $100,000 to $350,000 in six months. I naturally began to think about what do do with all that money, and had already ordered a Porsche and a golden bathtub.
Alice: Naturally.
Bob: But then all of the sudden, your system started losing money. My account went down and down and didn't stop going down.
Alice: How much?
Bob: It lost almost $150,000 in a single month. I'm now back at $210,000, and it's staying there since weeks.
Alice: Wins and losses follow a random sequence. Any system will eventually get a loss streak of any length and depth - that's mathematically certain.
Bob: I know, I know, it's a drawdown and I must just sit it out. But I don't have the nerve for that. Every morning I'm looking at the PC and my account is either going down, or not going up!
Alice: Put a blanket over your PC.
Bob: I got a much better idea. That's why I was on the way to you. What if the system traded with many assets at the same time?
Alice: Yes, that could increase the Sharpe Ratio when the assets are not correlated.
Bob: I have no idea what you mean with that. But I know that when EUR/USD is moving sidewards, chances are that a different pair, like USD/CHF, is just trending or cycling. So I lose with one but win with the other, if you get my meaning. And I can do this with a portfolio of many assets.
Alice: Certainly.
Bob: And can't you also combine your systems into one? I mean a super system that goes with the trend and against the trend at the same time? So I win when assets are trending and I also win when assets are cycling? Meaning I win all the time?
Alice: You won't win all the time because the equity curves of systems are often correlated. But it will certainly reduce your drawdowns and improve the Sharpe Ratio.
Bob: Well, then program this. I'll sell my Porsche and pay you well.
Alice: Good. I'll start at once. Now better go home and put some clothes on.

That's not an easy task that Alice got, and she has already decided to charge a hefty fee. Tomorrow we'll look into her first portfolio trading script.

Bob has given Alice the task to write a script that trades with several assets simultaneously, and uses both trend and counter-trend strategy algorithms. This is her first version (Workshop6_1 script, fee: $28,000):


The strategy is now divided into 3 different functions: tradeTrend for trend trading, tradeCounterTrend for counter trend trading, and the run function that sets up the parameters, selects the assets, and calls the two trade functions.

The first two functions look sort of familiar: They are just the two systems that Alice already had developed. Tomorrow we'll look into the stuff that is new.

Good stuff, keep it coming
Beginning to like zorro-trader and the way you are explaining is spot on

But I'm getting a little bit confused with your latest example
Obviously there is an auto variable(av) "Algo" that is set by the algo() function, right?
Is there also an av "Asset" that is set by asset()?
What I was wondering is that you don't have to pass the selected asset to the trading function. That would mean, that price() per default is set to the selected asset you're starting your script with and can be switched by the asset() function on a global basis?
Just like OrderSelect() in MT4 is making an excisting trade availlable on a global basis?

edit:
just found the answers to my questions in your online tutorial

Would it be possible to create a synthetic asset consisting of several "real" assets like a basket of currencies?
If so, would it be possible to run such a synthetic asset against an indicator or a filter?
The reason why I'm asking is this:
www.forexfactory.com/showthread.php?t=391229

It could be coded with MT5 but what I've seen so far is that the low quality of historical data even beats MT4

Yes, you can create a synthetic asset. Let's assume that you want to create an asset combined from the USD value of EUR, GBP, and CHF, then you would write a price function like this:


You can then create a series from that price and use all indicators with it. For buying and selling, you would buy and sell all 3 assets, like this:



This could be probably written in a more elegant way, using an external list for the basket components, but that's the basic idea.