Introduction
I had been planning to revise my implementation of the k-nearest neighbor algorithm (CPredictor) for over a year now. Last night I finally got it done and dusted. The main motivation for the revision was to simplify the use of the algorithm and to improve the quality of the predictions. Two worthy goals. Another task was to facilitate the use of multiple time series for pattern recognition. This article features a ‘trading system’ that was the result of the first test run.
The traded security is the SP futures contract. The trading simulation was run from June 1992 up to date. The CPredictor v2 was used to predict the change in an oscillator, called the WaveOsc2, two trading days into the future. If the prediction is positive then the system goes long and vice versa. In this case, the first test run, no trading delay was applied. All trades are ‘executed’ on the close of the day session.
The results of this run are 100% walk-forward. On any given trading day, only data up to that trading day is used by the CPredictor to generate the trading signal. This is an important point because nobody wants to see results that have been optimized over the trading simulation period. The trading system was built using the Dakota application. Dakota is a product of BioComp Systems Inc. and uses swarm adaptation to adjust model parameters on a strictly walk-forward basis. This improves the ability of systems to adapt to changing market regimes. It is reasonably straight-forward to implement your own trading models using the Dakota application framework.
System Settings
The screen images that follow detail the Dakota system settings and the settings for the CPredictor.
Reverse adjusted SP futures data provided by Pinnacle Data Corp. is selected. Data form 4/21/1998 is loaded. Approximately four years of data is required before the first trading signal is output for this system.
The period of the WaveOsc2 indicator has been set to 14 trading days. Using a parameter range that would enable adaptation of the period could well produce better results. As mentioned earlier, this was a test run. Ignore the ‘Predict Bars’ parameter. This is a function of the WaveOsc2 indicator that was not used. The Depth is the period to be used for pattern matching and is the only adapted parameter (one of the goals of the revision was to simplify). The Depth ranges from two to sixteen trading days. On any given trading day the trade bots within the swarm could be using a Depth anywhere within this range. It is the swarm adaptation algorithm that manages this. The Lookback period for the CPredictor is set to one thousand trading days or approximately four years. This is a trailing period that the pattern matching occurs over. Only twenty five trade bots are required because there is only one adapted parameter.
The equity engine that calculates and returns the proportion of perfect trading to the swarm adaptation engine has been selected. The performance is calculated over the last one thousand trading days or approximately four years. No trading delay has been applied and the system trades both long and short. The trading signal is determined by averaging the signal generated by all trade bots in the swarm.
Trading Simulation Results
The screen images that follow describe the trading simulation results.
The equity curve is reasonably consistent, although not super smooth. What I like about this equity curve is that it tends to move to new highs on a regular basis. This is impressive for a simulation that is 100% walk-forward. I wouldn’t trade using this system alone. However, I would definitely include this system in an ensemble of trading systems where each system contributes to the ensembles overall trading signal.
The trading statistics for the simulation are decent with relative equity straightness at 0.99 and percent of perfect trading at 8.3%.
Notes on the CPredictor
No detrending/normalization is done by the CPredictor algorithm. I wanted to leave this up to the systems developer so that different approaches can be applied. i.e. I didn’t want to lock anybody in. The algorithm requires a weakly stationary series as the input series to be predicted forward. You can feed it the raw price series if desired and it won’t complain, however, the results won’t be nearly as good.
Tip: How can we know what oscillators to use with the CPredictor for a given market? To start with, if knowing the change in the oscillator over the prediction period (e.g. next two trading days walking-forward) does not produce a great result then there is no point in attempting to predict the oscillator forward. This applies no matter what prediction algorithm is used.
Regards,
James
