|
PureBytes Links
Trading Reference Links
|
Bring it on Igor , I am very much interested if it works as you say it does.
your posting must have been sometime ago so sorry I missed it.
regards Jeff
----- Original Message -----
From: "raftsp" <raftsp@xxxxxxxxx>
To: <metastock@xxxxxxxxxxxxxxxxxx>
Sent: Friday, June 07, 2002 5:25 PM
Subject: RE: peak trough ...zigzag validity(trading safely with zig)
> 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
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002
|