|
PureBytes Links
Trading Reference Links
|
I hesitate to prolong this discussion but I hate to see some of these opinions go unchallenged.
I trading system is just a computer program. It does what the code tells it to do. If the code handles every situation that will ever occur, then perhaps you could turn it on and let it trade "untouched by human hands". But would you like to be flying in an airliner running on autopilot without a human pilot? I wouldn't. Why? Because something may happen that the programmer of the autopilot didn't anticipate and I would rather trust the human pilot to take control in such situations.
A good autopilot flies more consistently than does a human pilot, doesn't get tired, doesn't stop for lunch, doesn't talk with the cute flight attendant, etc., so generally does a better job in "normal" situations. But in an emergency, I want a human in the cockpit. I totally agree with Chuck LeBeau who wrote:
>Systems should not be overridden for directional or timing purposes but they
>should be overridden when it comes to issues of risk control. The highest or
>worst risk is the risk that cannot be quantified. These risks should
>definitely be avoided regardless of your trading style.
>
>Assessing many elements of risk is possible on a systematic basis but it can
>never be foolproof. If the discretionary assessment is that the risk is
>unknown or unacceptable then the system should be overridden.
You backtest your system to try it on as many kinds of events as you can find to see if it does something reasonable, just as you would test an autopilot. This historical data contains data errors, shock events, etc., so your resulting backtested profits will include those events.
If you have hundreds of trades and no one trade accounts for more than a few percent of the profits, then you can probably assume that the shock events hidden in your data didn't unduly influence the results. But if one trade makes, say, half of the profit and that trade was due to a shock event, then it is obviously unlikely that it will ever reoccur.
I also test my systems on test patterns - price patterns I designed and built using Excel to test the behavior of the systems on price events I think might happen. It is amazing what you can learn from test patterns. (There is a series of articles in Stocks & Commodities magazine recently by Charles E. Miller on this subject - called "Pseudo Securities". He and I both worked for the same test equipment company long ago so perhaps that is why we both tend to "measure" the performance of our systems with test patterns.)
>If you use historical results then to repeat those results you must take every trade no excuses.
Backtesting is simply a way to subject the code to past data to SIMULATE performance. That data will never repeat so the trades will never repeat. You backtest to see how the code will handle various situations that occurred in the past. That is all backtesting tells you. You can simply look at the results and assume that the overall performance in the future will be similar to what occurred in backtesting. Or you can look at each trade, both profitable and unprofitable to see if the system did something reasonable at each point. If it didn't, you can often add code to do a better job on those cases.
>No crashes, no medical reasons nothing should prevent you from taking every trade.
So you would stand by and let your autopilot fly you through a tornado...
>The point is this: If you do not take every trade, just as a robot would do, you may miss the trade which, in the long run, is the one which makes your system profitable.
No good system makes most of its profit on a single trade. With a good daytrading system, your are flat at the end of the day. So if you trade half the days, taken at random, on the average you should make about half the money. We all fail to take trades that would have been profitable. But opportunities to make money occur every day, lost capital is very hard to replace.
>Robert has raised two key issues that arise with "system trading": (1) The problem of price shocks. (Do not think that you can avoid them or that you know when they are coming. Price shocks are one of the fundamental reasons that systems do not survive long term.
Price shocks are part of the game but they affect all traders, not just system traders.
>(3) Real-time data problems. (I am convinced that there is a huge discrepancy between historical data which you might purchase and the data which appeared to traders over their real-time feeds at the time the historical data was supposedly captured. Those historical charts you're looking at... they didn't look that way to traders at the time.)
This is a bit of an exaggeration but I agree that real time data has gaps in time of several minutes, bad ticks, ticks out of time sequence, etc. (It always amuses me to see people you are looking for perfect historical data.) You need to handle these somehow either with a system or in discretionary trading. Most traders I know, have several sources in case of emergencies (real-time feed, listen only squawk, CNBC, etc.)
Returning to the autopilot analogy, when the plane makes a funny maneuver under the autopilot, the pilot looks at the instruments to see what is happening. Most system traders I know have indicators that show all of the key variable in their system. And when the system signals a trade, they glance at the indicators to make sure things look "normal". That way, when their system signals a breakout as a result of a bad tick, far from current prices, they do not blindly place the order!
>Incorporate these price shocks into your systems. If you don't, them your system is invalid. These things happens and you must account for them.
This sound good on the surface but is hard to do. In most real-time control systems, if you have code to handle, say, 80% of the cases, it might require twice as much code to handle 90% of the cases. and twice again as much code to handle 95% of the cases, etc. As you add more ways to enter and exit trades, you have to worry about interactions between signals.
Of course, the usual (brute force) way to handle this is to just use stops to get you out ungracefully in those cases that your code cannot handle gracefully. (But then you need to make sure that your system code doesn't just kick you back in right after you were stopped out.)
Bob Fulks
|