[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: peak trough ...zigzag validity(trading safely with zig)



PureBytes Links

Trading Reference Links

Thanks for clarifying that Igor , forgive me for getting a little excited
there , I thought you had formulated an astounding indicator for a moment ,
I guess I must still be searching for the elusive ' holy grail '.
thanks again Igor.
----- Original Message -----
From: "Igor" <igor.devisscher@xxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>; "'jeff'" <jcadman@xxxxxxxxxxxxxx>
Sent: Saturday, June 08, 2002 1:15 AM
Subject: RE: peak trough ...zigzag validity(trading safely with zig)


> Hy jeff,
> I have nothing to bring on...on the contraries I have something that
> does NOT work because it is based on peak and trough and so I get
> signals witch afterwards disappear again. If I backtest it always gives
> VERY good results. Witch is normal when a system in realtime gives
> signals or takes positions but when it feels that they are loosing it
> pulls the signal back like it never took the position. In that way it is
> always a winner. So my question is how do you know when a peak or a
> trough is 100% reliable and that it will not take a way a signal
> anymore.
> When you read the part at the bottom of this mail, Owen Davies had the
> same problem. The only answer to his problem came from Al taglavore. He
> claimed that the problem is due to the fact that peak and trough work
> with a zig zag indicator. But that is no solution to this problem. So
> how can we solve this problem. Maybe it can be done with the SR zig zag
> function who gives conformation that a zig zag signal is 100% reliable.
> Or maybe someone else has an other solution to this problem ??
> Greetings igor
> PS the text below is a mixture af all different mails, and is not coming
> from me. The only part I wrote was: ...."  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.?..."
>
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx] On Behalf Of jeff
> Sent: vrijdag 7 juni 2002 16:16
> To: metastock@xxxxxxxxxxxxx
> Subject: Re: peak trough ...zigzag validity(trading safely with zig)
>
> 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
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.370 / Virus Database: 205 - Release Date: 6/5/2002