|
PureBytes Links
Trading Reference Links
|
Igor:
Some time ago I posted an indicator of mine called "ZigZag Validity" which
checks if the last dynamic leg of Zig is trusty or not. It is a binary
indicator that returns 1(=valid) or 0(=invalid). It is useful for
validating only the CURRENT value of zig. It is NOT suitable for back tests
and systems. If you want to be able to use a valid zig function in systems,
then use my latest "SR ZigZag Trend". Read below.
Owen:
For better understanding the zigzag functions (zig, peaks and troughs) and
how my ZigZag validity works, you may read my article (titled "ZigZag
validity") that will be published in the August issue of the Stocks and
Commodities magazine. In the meanwhile you can review my past messages.
Everyone:
A few days ago I posted a new indicator of mine called "SR ZigZag Trend",
which, as I believe, solves for good every problem related to the dynamic
nature of zig. To my surprise, there were no reactions, no replies, nothing!
The enthusiasm about ZigZag validity (a simple, not very handy indicator)
now gave place to total indifference to a new indicator, which actually
marks the end of the zig myth! This is a also a binary indicator which
returns 1(=confirmed uptrend) or -1(=confirmed downtrend). In my lengthy
message to the group I explained that SR Zigzag Trend:
1. is always valid. To put it simply: WYSIWYG (What You See Is What You
Get). No revisions, no redraws! Never!
2. can be used as a stand-alone indicator in Zig's place.
3. can be used safely in systems and back tests. Where one would like to
use zig (but did not dare to), now he can use SR Zigzag trend and that's it!
What's more, by pasting the code to his system one can even optimize the
percent parameter!
4. can also be used in experts, explorations and everywhere as any other
custom formula.
Isn't this strange? An indicator which solves a problem as old as zig and
which could be easily sold for $### is offered for free and nobody seems to
have noticed it!
Anyhow, try these indicators (especially SR ZigZag Trend) and tell me what
you think. If you don't have the codes I can post them once more.
Spyros
Date: Thu, 6 Jun 2002 01:32:51 +0200
From: "Igor" <igor.devisscher@xxxxxxxxxx>
Subject: peak trough ...zigzag validity
This is a multi-part message in MIME format.
- ------=_NextPart_000_001A_01C20CFA.134A9F10
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Hy list,
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.?...
greetings
To: <metastock@xxxxxxxxxxxxx>
Subject: Re: Peak and trough
From: "Al Taglavore" <altag@xxxxxxxxxx <mailto:altag@xxxxxxxxxxxxx> >
Date: Wed, 24 Oct 2001 13:27:55 -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>> 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 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
: 19/04/02
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/02
|