As computers have increased in speed and functionality, more steps of the trading process have become automated. Now, advances in software design are pushing those limits even further, so much so that even the process of building a trading system itself can be done with little human input.
Last month, we showed how these new tools operate. This month, we put them to work in the gold market.
First, we need to extract and preprocess the data necessary for our trading system from our sample market; in this case we’ll use gold futures. We do this by running a special trading system in data extraction mode (see “Digging for data.”).
Before we start our automation run, we need to feed the computer some basic information setting ground rules for the automated process. We input data such as big point value, account size, minimum fluctuation value and which performance statistic we want the software to monitor. After just a couple minutes of processing time, we can see how the evolved equity curve is becoming profitable (see “Getting there.”).
After just a few minutes of run time, more than 30,760 trading systems were developed. Again, these are not individual optimizations of a few trading systems. These are entirely different systems, logically and parametrically. The AIM-GP moves blocks of evolved code around the evolutionary environment formulating new and unique trading systems.
The system produced positive performance in both training and out-of-sample testing (you can find these performance numbers on the “downloads” section of www.Futuresmag.com or the link below). The out-of-sample testing reflects the robustness of the trading system because there was no significant drop off in performance. Remember, we are not forecasting the direction of the market to some point in the future, but we’re measuring how well our evolved trading system performs on both in-sample data and out-of-sample data.
Many developers limit or eliminate out-of-sample testing, and therefore their trading systems usually fall apart as they are used into the future. Also, note that our results could be improved with more runs. Indeed, simply rerunning the same test again will often result in improved performance. This is due to initialized random seeds and the random effects of evolution. One simple random mutation can make improvements.
Throughout the long haul, if our input set contributes to the general robustness of an evolved trading system and if the evolutionary algorithm converges properly, more runs will show good results than will show poor results; and a robust trading system will emerge quickly, very possibly on the first run.
As a last step, we will translate the Genetic Program generated C code into EasyLanguage and run our trading system in TradeStation. The results of the final trading system are shown in “Final run.”
INSIDE THE SYSTEM
Lets look at our example, the evolved EasyLanguage program shown in “Heart of the system” (below). The AIM-GP ignored 56 of the 62 inputs, making use of only six:
v1[6], v1[11], v1[23], v1[25], v1[29] and v1[33].
These inputs are defined below:
v1[6] = low > low[1] and low[1] > low[2] and high > high[1] and high[1] > high[2];
v1[11] = atr11 < atr22;
v1[23] = close < lowest (close, 4) + rng*sdv*3;
v1[25] = high>high[1];
v1[29] = high>high[3];
v1[33] = close>=close[1];
Where:
atr11 = average(range, 8);
atr22 = average(truerange, 20);
rng = Highest(high, 4) - Lowest(low, 4);
rng3 = Highest(high, 10) - Lowest(low, 10);
LR = LinearRegValue(close, 10, 0);
Sdv = StdDev((close-LR), 10)/rng3;
After a few applications of square root, addition, subtraction, multiplication and absolute value, we have our trading system.
Looking at the evolved code, we see that machine-learning code is quite different from traditional human-supplied code. We write code that we can usually understand or verbalize. The GP writes code simply to solve the problem; nothing else matters.
In this case, the GP preferred certain patterns and indicators that appear to the casual observer to be bullish, even though the number of short trades is nearly identical to the number of long trades. More profit was made on the long side than on the short side, probably due to the upward bias of the gold market throughout the past five years.
Note that because the GP can switch directional use of any indicator easily, what were once bullish patterns or indicators may quickly become bearish or neutral, controlled by yet another GP evolved subprogram. The base system code is rather tight, only a page or so of translated EasyLanguage code. To evolve this code, the GP had to move through the other 56 inputs quickly, combining, mutating and recombining features and equations to determine there was nothing of importance in those 56 inputs.
There also will be sections of the code that really do nothing. This is the GP’s own software bloat, called introns. If we wish, we may remove these introns after our system has been generated. After removing the bloat and adding the inputs and entry signals, we get the simplified code also shown in “Heart of the system.”
POINTS OF CONSIDERATION
A few additional concerns are important. First, this is only a sample system. It is not recommended that you actually trade this program. To build a complete trading system, you would want to use all the price history available for the contract (there is a 7300-day evolved gold futures equity curve on the TSL Website). Also, there are several areas of analysis, such as cycle analysis, that could still be exploited to improve the system. Additionally, intermarket data, options-related data, Commitments of Traders data and fundamental data could be included .
Combing through the trading system logic, it’s interesting to see some of the rules. For example, a human likely would never consider adding together the Boolean variables of two independent patterns, but the GP does. Why? Because that’s what works. The GP has no predefined bias as to how technical analysis should evolve.
The GP has not been exposed to volumes of literature on trading or countless pages of chart analysis written by chart readers through the centuries. It does not care that a pattern-based Boolean input was just divided by an indicator-based Boolean input and subtracted from yet another input. All it is programmed to do is to evolve the most robust trading system or indicator that it can.
As humans, we are preconditioned, based on years of studying literature on systems and indicators, to what ought to work by observation and deliberate analysis. We have to accept new and different technical analysis equations, much like a mathematician has to accept various computational paths to solve the same problem.
We also may not immediately understand the mathematics that the GP creates because our own internal programming is used to evaluate the mathematics that we are looking at, and if the GP’s math does not fit into our own pattern of knowledge, we often have trouble accepting it.
Recent history has shown that many systems designed by humans using manual techniques have failed in the market. Additional studies reveal the frailties of predictive analytics. The markets have no closed form mathematical solution. Computer programs now design aircraft without wind tunnels, life saving medicines with software-based clinical trials, chess moves that beat the masters and implement security protocols for our direct protection, so using computers to design trading algorithms is not a big step.
Note: Testing results and the code for the system can be found on the “downloads” section of www.Futuresmag.com or in the link below.
Michael L. Barna is a registered CTA and president of Trading System Lab. He has degrees in mathematics and astronautical engineering. Reach him at www.tradingsystemlab.com.
