[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

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