Every system developer has a list of rules and indicators that they want to test out. The problem every developer faces is narrowing down that list of rules and indicators to the select few that are best worth focusing on. A quite similar and related problem that every developer has to deal with is having some inputs or indicators that they believe to be relevant and important but not knowing exactly in what way they are significant. I will show you how you can quickly find the best rules and indicators to focus on using an automated search approach which will work on most traditional retail trading platforms (such as Tradestation, Multicharts, Ninjatrader, Amibroker, etc.). But first I should point out that there are two basic approaches to developing systems.
The manual method also known as the hypothesis and test method (guess and check), quite similar to the scientific method, and the generative method also often thought of as the “data mining” approach. It seems that most professionals use the scientific method because the generative method lacks sufficient control over the process. The problem with the traditional method is that it can be really slow and self-limiting.
Computers today are tremendously powerful and fast, and yet the system developer using the traditional approach derives very little benefit from all that increased computing power and resources. Clearly, a developer who can’t utilize the advances in technology will be at a significant handicap.
Fortunately, it is not an either-or scenario because the optimizers found in retail trading platforms can be used for not just optimizing inputs but also for discovering the best trading inputs and rules to use. The key idea is to use the optimizer to find the most relevant rules or indicators. One of the first ideas that I had was to chain conditions together using operators such as “or” and “and”. This can be achieved by creating an array of rules with associated bit states which the optimizer can turn on and off.
Tradestation has the limitation that it can’t optimize Boolean fields. The solution is to simply convert everything to “0” and “1” numeric. Create a list of rules and allow the optimizer to turn them on or off.
Inputs:
BuyCondition0(0),
BuyCondition1(0),
BuyCondition2(0);
Arrays:
BuyConditions[5](0);
BuyConditions[0] = IFF(Close > Close[1],1,0);
BuyConditions[1] = IFF(High > High[1],1,0);
BuyConditions[2] = ....More rules and conditions follow
if BuyConditions[0] = BuyCondition0 or
BuyConditions[1] = BuyCondition1 or
A rule must both be turned on and have its corresponding input set to true for it to trigger. This allows the optimizer to turn rules on and off. Each associated “buy condition” is optimized (0 to 1, step 1). The method works and is quite powerful in itself. But the problem is you might start to think maybe we should link the rules together using an AND statement instead. OR means any rule can be own whereas AND requires all the rules to be true.
Also, maybe some conditions should signal to the system not to take a trade; that they have negative input. The number of inputs multiplies and the method quickly become unworkable. Clearly, while this method is powerful, it has too many limitations. The solution is to change the Boolean “on/off” conditions to weights, as shown below:
BuyConditions[5](0);
BuyConditions[0] = IFF(Close > Close[1],1,0) * w0;
BuyConditions[1] = IFF(High > High[1],1,0) * w1;
BuyConditions[2] = ....More rules and conditions follow
if (
BuyConditions[0] +
BuyConditions[1] +
) > thresholdBuy
We sum the weights and a buy is only triggered when the combined weights are greater than our threshold value. This is known as a perceptron. The perceptron is the precursor to the much more advanced neural network (a question for mathematical folks, what’s the difference between this and a linear function approximator?).
For simple searches, you optimize the weights with values 0 or 1. However, you can create partial weighted functions where multiple inputs can contribute to the output by optimizing from 0 to 1 in fractional increments. By changing the step size, you can define the minimum contribution that each input needs to have for the perceptron to “fire”. For example, if your threshold is 1 and your minimum step is .5 then any indicator would need to contribute at least 50% to have an impact or else would be forced into the off state.
An additional reason why this model is more powerful is that you can optimize from -1 to 1 which enables indicators to have a negative or inhibitory effect. Perceptron search can quickly reveal which rules and indicators are most likely to be relevant and worthy of additional exploration. As for techniques for additional development, converting the trading signals into normalized continuous output functions could eliminate the need to even define the initial rules.
— by Curtis White from blog Beyond Backtesting
Great article! I think the concept and implementation is innovative.
However, I am wondering why this is all necessary when TradeStation offers Portfolio Maestro which can execute (and optimize) a set of strategies across multiple lists of instruments? It also can include money management rules, considers commissions, etc.
What are pluses and minuses of each approach?
I would have to say you’re talking about two completely different items. The perceptron search is a coding technique while Portfolio Maestro is backtesting tool. With the perceptron search, you’re testing the impact of individual trading rules against one another. You’re also testing how each rule interacts with the other rules to produce trading signals with favorable outcomes (net profit vs. drawdown, for example). Since the perceptron search is written in EasyLanguage, you’re unlimited in testing different types of indicators. Once you have a strategy, you can then use Portfolio Maestro to test your strategy against a basket of symbols. In the end, one could use a perceptron search and Portfolio Maestro independently.
I did something similar years back. I got the idea from an article from the creator of Adaptrade builder, but it was easy to program in Easy Language. I actually found that the entry rarely mattered. It was the exit that determined profitability.
I’ve heard that a few times…it’s all about the exit!