|
PureBytes Links
Trading Reference Links
|
Owen:
IMO, there are two essential aspects of system
development - testing data not used in developing the system and shooting for a
robust system, which is not necessarily the most profitable one. There are
programs that help you find robust conditions, but the bottom line is to have a
system that is insensitive to changes in variables. It is also important
that the system trade in accordance with your "style." Here is an outline
of Kaufman's rules for system development:
1. Select a trading strategy with a sound
underlying premise; complexity is not necessary
2. Reserve out-of-sample data for
validation
3. Select the range of parameters to test that
is logical, favoring the faster or slower trading approach
4. Perform the longest reasonable test to
include as many market situation as possible
5. Test as many different markets as possible
looking for a common pattern in the results
6. Standardize the results to facilitate
comparisons between systems and test periods
7. Evaluate the robustness of the method rather
than the peak performance; avoid fine tuning
8. Assess the effect of past price shocks on
profit and risk
9. Beta-test (paper trade) the system until you
are certain that it is working properly
Good luck.
Bill
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
----- Original Message -----
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From:
Owen Davies
To: <A title=metastock@xxxxxxxxxxxxx
href="mailto:metastock@xxxxxxxxxxxxx";>metastock@xxxxxxxxxxxxx
Sent: Wednesday, October 24, 2001 3:58
PM
Subject: Peak and trough
Among the many things I don't understand, this one hasbeen
bothering me of late:A while back, I decided to check one of my
assumptionsand test the higher-high, higher-low/lower-high,
lower-lowdefinition of trends. The easy way was to create a
systemusing peak() and trough(). It worked beautifully.
Virtuallyany contract I ran the system past, it made money.
ThisI took to confirm the validity of the trend definition.Then
the obvious dawned on me: Why not see whether therewas enough of the
move left, on average, to make a buck from itafter the peak or trough was
far enough behind us to get thesignal in real time? I wrote another
system that included a delayfactor, so that one would enter or exit a
trade only when theprice had retraced from the peak or trough by the
appropriatepercentage. Again, it worked just fine. In
historical testing, itmade money like magic on anything from 5-minute to
daily bars.Problem: When I put it on real-time data, it gave a
lot of badsignals. Then it suddenly recalculated things, decided
that theminor up and down trends of the last few weeks--this wason
smallish intraday bars--had really been a long up trend,gave a new set of
signals, and declared itself a winner.Does anyone understand these
functions well enough toexplain this behavior to me? I knew that
peak() and trough()backdate their results by putting their signal several
barsbefore it was possible to receive it; that is what I was tryingto
correct with the delay factor. Now it seems that theyalso
recalculate their old percentages by comparing againstthe latest data
rather than limiting themselves to the datathat available in real
time.No doubt this is a real beginner's mistake (despite
havingplayed with this for years), but it would have seemedreasonable
to assume that a change of X% three weeks agoshould remain X%, even if we
looked at it later. This sortof thing has to be seen within its
context, or it's useless.Is there some reason the functions have to be
written this way,which I'm completely overlooking, or did someone
justbutcher this piece of code?Many thanks.Owen
Davies
|