|
PureBytes Links
Trading Reference Links
|
OK thanks for help but the result is still to noisy and doesn't seem to achieve what I'm seeking ..
I'm trying to apply the philosophy behind an AMA to make a variable length Oscillator.
the idea is to have the length of your favorite oscillator extend in the context of a trend and shorten when a trend is not evident. I thought I could do this by defining the length of the cycle which I thought would be greater if the market was trending but I get too much noise.
so then I went to looking at the pursuit of "intersection"
If say
Low>high[2] and Low[1]>High[3]) or (high<low[2] and high[1]<low[3]); then bars are not intersecting and a trend or at least a 2 day gap has opened up so I want to extend the (say) RSI length by a day. If the condition is true for 2 days in a row then extend the length by 2 days .. from a Min of say 5 to a max of say 20 .. so one doesn't do any testing for the all important length input.
Any ideas?
CJE
----- Original Message -----
From: "Gary Fritz" <fritz@xxxxxxxx>
To: "Chris Evans" <evanscje@xxxxxxxxxxxxx>
Cc: <omega-list@xxxxxxxxxx>
Sent: Tuesday, January 13, 2004 10:57 AM
Subject: Re: Cycle Length
> > this horse still isn't drinking ..
>
> Chris, you still have several logical errors in here.
>
> First off, I've told you several times that if you're going to
> scan for a minimum value of Sum_Price_Chg or whatever, you need
> to RESET your value of Save on EVERY BAR, because you're trying
> to recalculate your cycle length on every bar. If you don't
> reset Save, then you're comparing the current Sum_Price_Chg
> against the lowest value you EVER found on the chart.
>
> Second, you're doing a variable-length Summation of the xavg-xavg
> expression. I think Gary Funck pointed out that when you SUM UP
> 20 xavg-xavg terms, it's almost always going to be a bigger
> number than SUMMING UP 5 of them! So the shortest length (5)
> almost always wins. It would make a bit more sense to use an
> AVERAGE.
>
> Third, in this incarnation of the code, you're not even paying
> attention to the summation. Instead, you're looking for the
> lowest value of another xavg-xavg expression, which will be
> lowest when the cycle component of the price is lowest, and
> that's not at all what you want. Plot the xaverage(Price,Max)-
> xaverage(Price,len) expression to see what I mean.
>
> If you make the above changes:
>
> Inputs:Price(c),Max(50);
> Vars:len(1),Min(99999),Save(10),Sumofchange(0),Cyclelen(0);
> Save = 999999;
> For Len=5 to Max begin
> Min=Average(XAverage(price,3)-XAverage(Price,100),len);
> If AbsValue(Min)<Save then begin
> Cyclelen=len;
> Save=AbsValue(Min);
> end;
> end;
> plot1(cyclelen, "CL");
>
> ...you do at least get SOME reasonable values. But I still think
> this is a flawed approach. I think you'll get more reasonable
> values with an LRS approach like I originally proposed:
>
> Inputs: Price(c),Max(50);
> Vars: LRS(0),Cross(0),Cyclelength(0);
> LRS = LinearRegSlope(xaverage(c,3)-xaverage(c,100),10);
> if LRS crosses over 0 then begin
> CycleLength = .1*(CurrentBar - Cross) + .9*CycleLength;
> Cross = CurrentBar;
> end;
> plot1(cyclelength, "CL");
>
> This code only adjusts its cycle-length value once per cycle,
> rather than on every bar. But it produces a whole lot more
> reasonable results than I can get out of your approach.
>
> Gary
>
|