|
PureBytes Links
Trading Reference Links
|
<span
style='font-size:10.0pt;font-family:Arial;color:navy'>
<span
style='font-size:10.0pt;font-family:Arial;color:navy'>Hy<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'> list,
<span style='font-size:
10.0pt;font-family:Arial;color:navy'>I found this text on the internet. Is
there a solution to this problem?...Is there a way
that you know that a signal will stay and NOT afterwards disappear to call
itself a winner in the results of the tester. Is the zigzag validity maybe a
solution to this problem. There has to be a way that
one knows that a peak or a trough is a 100% true signal…?...
<span
style='font-size:10.0pt;font-family:Arial;color:navy'>greetings<font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>
<font size=3 color="#ff0080"
face="Trebuchet MS"><span style='font-size:12.0pt;font-family:"Trebuchet MS";
mso-bidi-font-family:Arial;color:#FF0080'>
To: <metastock@xxxxxxxxxxxxx<span
class=GramE>>
Subject: Re: Peak and trough
From: "Al Taglavore" <altag@xxxxxxxxxx>
Date: <font
color="#ff0080" face="Trebuchet MS"><span style='font-family:"Trebuchet MS";
mso-bidi-font-family:Arial;color:#FF0080'>Wed, 24 Oct 2001<font
color="#ff0080" face="Trebuchet MS"><span style='font-family:"Trebuchet MS";
mso-bidi-font-family:Arial;color:#FF0080'> <st1:time Hour="13"
Minute="27"><span style='font-family:
"Trebuchet MS";mso-bidi-font-family:Arial;color:#FF0080'>13:27:55<font
color="#ff0080" face="Trebuchet MS"><span style='font-family:"Trebuchet MS";
mso-bidi-font-family:Arial;color:#FF0080'> -0500
Reply-To: metastock@xxxxxxxxxxxxx
Sender: owner-metastock@xxxxxxxxxxxxx
Perhaps the problem can be assigned to the Zig Zag feature that is used inPeaks
and Troughs. Refer to MetaStock manual (ver 7.03) page 528:"Be
forewarned, that the last leg (i.e., segment of the Zig Zag is dynamic,meaning
that it can change. Therefore, be careful when designing systemtests,
experts, etc. based on the Zig Zag indicator."Al Taglavore---------->
From: Owen Davies <owen@xxxxxxxxxxxxx>> <font
color=blue face="Trebuchet MS"><span style='font-family:"Trebuchet MS";
mso-bidi-font-family:Arial;color:blue'>To: metastock@xxxxxxxxxxxxx> Subject:
Peak and trough> Date: Wednesday, October 24, 2001 2:58 PM> > Among
the many things I don't understand, this one has> been bothering me of
late:> > A while back, I decided to check one of my assumptions> and
test the higher-high, higher-low/lower-high, lower-low> definition of
trends. The easy way was to create a system> using peak()
and trough(). It worked beautifully. Virtually> any contract I
ran the system past, it made money. This> I took to confirm the
validity of the trend definition.> > Then the obvious dawned on me:
Why not see whether there> was enough of the move left, on average, to
make a buck from it> after the peak or trough was far enough behind us to
get the> signal in real time? I wrote another system that included a
delay> factor, so that one would enter or exit a trade only when the>
price had retraced from the peak or trough by the appropriate> percentage.
Again, it worked just fine. In historical testing, it> made
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 bad> signals.
Then it suddenly recalculated things, decided that the> minor up and
down trends of the last few weeks--this was> on 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 to>
explain this behavior to me? I knew that peak()
and trough()> backdate their results by putting their signal several
bars> before it was possible to receive it; that is what I was trying> to
correct with the delay factor. Now it seems that they> also
recalculate their old percentages by comparing against> the latest data
rather than limiting themselves to the data> that available in real
time.> > No doubt this is a real beginner's mistake (despite having>
played with this for years), but it would have seemed> reasonable to assume
that a change of X% three weeks ago> should remain X%, even if we looked at
it later. This sort> of thing has to be seen within its context, or <span
class=GramE>it's useless.> Is there some reason the functions have to
be written this way,> which I'm completely overlooking, or did someone
just> butcher this piece of code?> > Many thanks.> > Owen Davies
|