|
PureBytes Links
Trading Reference Links
|
> -----Message d'origine-----
> De : Bob Fulks [mailto:bfulks@xxxxxxxxxxxx]
> Envoye : lundi 30 juillet 2001 21:01
> A : Jack Griffin
> Cc : Rich Estrem; omega-list@xxxxxxxxxx
> Objet : Re: AW: TradeStation Precision - Summary
>
>
> At 6:42 AM -0800 7/30/01, Rich Estrem wrote:
>
> >run on TS Pro:
> >
> >200-bar EMA as suggested by Mike below, run on 1 min $INDU data:
> >
> >ending value run on 1360 bars = 10417.33
> >ending value run on 54,206 bars = 10417.33
> >
> >(excel result on 1567 bars = 10417.33)
> >
> >I don't doubt that some calc's do lose precision over multiple
> >iterations in TS, but clearly the EMA is not a good example to show
> >this problem.
>
>
> At 6:43 AM -0700 7/30/01, Jack Griffin wrote:
>
> >People this should be obvious --- the ema
> >automatically eliminates any cumulative errors due to
> >the what is it. The SMA, DMI, OBV, ect. is where this
> >type of thing shows up.
>
> To add more detail to Jack's point, the EMA will not show this affect
> because it does not accumulate the error even though it seems as if
> it should:
>
> Its equation is:
>
> XAverage = Factor * Price + (1 - Factor) * XAverage[1]
>
> So with values: Price = 10000.000 Factor = 0.01000000
>
> XAverage = 0.01000000 * 10000.000 + 0.99 * 10000.000
>
> Max = 100.00001 + 9900.001 = 10000.001
> Nominal = 100.00000 + 9900.000 = 10000.000
> Min = 99.99999 + 9899.999 = 9999.999
>
> So the error will be randomly in the 7th significant digit -
> sometimes plus and sometime minus - and gets attenuated by
> (1 - Factor) so does not accumulate.
>
Well said, but is accumulates a bit ( depends on factor -I used 2/21 with a
10 bars xaverage and the cosine example II)
> A better example is the simple moving average version that
> accumulates the value form bar to bar. It appears to be called
> "Average(series)" in TS4.0 and "AverageFC" in TS2000i.
>
> It contain the term:
>
> Sum = Sum[1] + Price - Price[Length];
>
> In this case the errors accumulate without attenuation.
Yes, and you do not have to use this function that should be used mainly
with RadarScreen ( FC functions were introduced with Prosuite).
Again it's a matter of understanding what the user currently does.
>
> I ran a quick test and see errors of about 0.1 in about 9000 bars of
> INDU with a Length of 124. That is about 100 times the one part in
> 10^7 error on a single calculation and just about at the point where
> it might start becoming important. (The error depends a lot on the
> number of bars and the Length since it is the sum of random round-off
> errors each of near 1 part on 10^7.)
>
> As Jack said, the errors accumulate in functions such as SMA, DMI,
> OBV, etc., that accumulate a sum without attenuation. Lots of
> functions do this including common ones such as RSI.
>
DMI, RSI accumulates with attenuation :
See the DMI code
{MinusDM not set to 0 because it is not used}
If MyRange > 0 Then Begin
TRange = TRange[1] - (TRange[1] / MyRange) + TrueRange;
PlusDM14 = PlusDM14[1] - (PlusDM14[1] / MyRange) + PlusDM;
End;
If TRange <> 0 Then
DMIPlus = 100 * PlusDM14 / TRange
Else
DMIPlus = 0 ;
End ;
And lok at the RSI code
If CurrentBar > 1 AND Length > 0 Then Begin
UpAmt = Price[0] - Price[1];
If UpAmt >= 0 Then
DownAmt = 0
Else Begin
DownAmt = -UpAmt;
UpAmt = 0;
End;
UpAvg = (UpAvg[1] * (Length - 1) + UpAmt) / Length;
DownAvg = (DownAvg[1] * (Length - 1) + DownAmt) / Length;
End;
If UpAvg + DownAvg <> 0 Then
RSI = 100 * UpAvg / (UpAvg + DownAvg)
Else
RSI = 0;
> The error will grow much faster in functions that subtract two near
> equal values as I have pointed out before. Statistical functions such
> as LinearRegValue and LinearRegValue subtract two near equal large
> numbers, for example.
This is not exactly true:
Check the big numbers (BN) in the code
SumBars = 0;
SumSqrBars = 0;
SumY = 0;
Sum1 = 0;
Sum2 = 0;
SumY = Summation(Price, Len); <=====first BN, not affected by 7 digit
precision ( like the normal average with loop)
SumBars = Len * (Len - 1) * .5;
SumSqrBars = (Len - 1) * Len * (2 * Len - 1) / 6; <=====they are constant
For X = 0 To Len - 1 Begin
Sum1 = Sum1 + X * Price[X];<=======second BN, X being an index multiplying,
it will not overflow 6 digit precision
End;
Sum2 = SumBars * SumY; <========== BN3= constant * BN1, precision preserved
Num1 = Len * Sum1 - Sum2; <========= BN4 may lose precision if these numbers
are very different, 10^2 factor at least ( means a slope close to 0,this is
where the precision problem could be)
Num2 = SumBars * SumBars - Len * SumSqrBars; <===This is a constant
If Num2 <> 0 Then
Slope = Num1 / Num2 <== admit that the epsilon slope in not correct
because of Num1, as you divide by num2, means that anyway the slope is
really very, very close of zero, the error on epsilon being divided by Num2,
that should be a positive constant >>0
Else
Slope = 0;
You may also recalculate the relative error from price error as I did to
verify thay it complies with price precision, but I have no time to do so.
To summary, the slope error may affect a zero slope by epsilon for large
Length and / or Price values.
To fix this , see the usual workaround section if you estimate that it is
worth the time to spend on it.
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies representative in France
|