Custom Search

Developmental History

When I began designing systems for currency trading in TradeStation several years ago I was quick to notice that the optimal variables which controlled the system equations would vary greatly from one contract month to another. My initial methodology involved an early range breakout system for trading the currency markets whereby the system would place breakout buy or sell stops slightly outside the early market range. Since the definition of the early range was critical to system performance, variables were used in the system to set the range by time of day, width of the early range, and the proximity of the current price to extreme range when the early range was defined.

  It was soon obvious that the best settings for the variables used to define the critical early range varied significantly from contract to contract. Even averaging the variables over several contracts produced only mediocre results. Obviously there was a characteristic somewhere in the activity of the market that was fluctuating regularly which resulted in the radical activity of the system. Also obviously, if the system was to be profitable in the future, I was going to get a handle on the root of these fluctuations. One could always optimize the variables for each contract and make the system look like the best thing around but we all know by now that curve fitting is a quick way to overconfidence and a losing system.

For months I analyzed every market parameter I could define - gaps, average daily range, daily open to close, ratios of high to low to open to close, tendency of a quiet day to follow a wild day, changes of market activity around big report days, and so on. Although measuring these parameters and using them to adjust the system variables was of some benefit to system performance, I was still unable to achieve the consistency across all data that I desired.

Then one day it dawned on me - the best way to evaluate the market with respect to a particular system is the system itself! By running the system against a defined subset of past market data using a defined set of variables one could constantly monitor the performance of the system across all variable settings. Properly programmed, the system could constantly adjust critical variables to reflect optimum performance against recent market data.

This technique operates in much the same fashion in which the pure market technician assesses the market. The pure technician ignores all fundamentals, confident that eventually all forces impacting on the market will be reflected in price. In much the same way, a parallel user function ignores all the myriad of technical forces in the market as they impact the system and concentrates only on the net effect of these changes in market characteristic on the system itself. Rather than trying to determine which phase of market activity is impacting the results of the system, we use the system itself to monitor changes in the market personality and make system adjustments accordingly.

To accomplish this formidable task I created what I have chosen to call a parallel user function.