Baluda Indicators

[garyfritz]

Paul, I wanted to start implementing some of these things in Tradestation so I could backtest them. The first thing was to implement Slope. TS doesn't have a LWMA indicator so I wrote one myself. As far as I can tell it's accurate -- but it doesn't match your (or Neo's) Slope calculations. It's much noisier and more jagged.

So I modified your TMA Slope MTF indi to look at the values your GetSlope() uses. Excerpt of what I did:

Code: Select all

   SetIndexBuffer(0, MAnow);
   SetIndexBuffer(1, MAprev);
   SetIndexLabel(0, "Now");
   SetIndexLabel(1, "Prev");

// In start():

   for ( i = 0; i < limit; i++ )
   {
		MAnow[i] = calcTmaTrue(Symbol(), 0, i) * 10000;
		MAprev[i] = calcPrevTrue(Symbol(), 0, i) * 10000;
   }

I expected the MAnow (calcTmaTrue) value on e.g. the 10:00 M30 bar should exactly match the MAprev (calcPrevTrue) value on the next (10:30) bar. But it doesn't.

E.g. on 31 Aug, GMT+0:

Time Prev Now
09:00 1.25178056 1.25184035
09:30 1.25218295 1.25225766
10:00 1.25264032 1.25273623
10:30 1.25316602 1.25328528

There are some pretty significant differences, considering how little it changes from bar to bar.

It looks to me like calcPrevTrue() is supposed to be equivalent to calcTmaTrue() on the previous bar. So I tried changing your GetSlope() code to:

Code: Select all

      double dblTma = calcTmaTrue( symbol, tf, shiftWithoutSunday );
      double dblPrev = calcTmaTrue( symbol, tf, shiftWithoutSunday+1 );

That's not nearly as smooth -- and in fact it looks almost exactly like my Slope calculation on TS.

What is calcPrevTrue( , , x) doing that's different to calcTmaTrue( , , x+1) ?? The only difference I see is that calcPrevTrue() inits the dblSum and dblSumw to iClose( symbol, tf, inx ) * 20 and 20, but I don't understand why -- why include the inx bar in the Prev calculation?? And why weight that one at 20, then weight inx+1 at 21, inx+2 at 20, etc??

I'd suspect there's a logic bug in there, but you and Neo's indicators produce the same results. He hasn't released his code so maybe he just "borrowed" your Slope code...

[gaheitman]

I'd suspect there's a logic bug in there, but you and Neo's indicators produce the same results. He hasn't released his code so maybe he just "borrowed" your Slope code...

I believe he is including the first bar of the right side of the triangle from the original tma indicator.

George

[garyfritz]

That's the logic bug I suspected... I don't see why you'd want to do that. That's "future-peeking" that we've been trying to avoid with the "TMA" indis. (Well, not exactly. See comment at bottom.)

If I initialize dblSum and dblSumw to 0 (in calcPrevTrue()), then calcPrevTrue( , , x) == calcTmaTrue( , , x+1), which I think it should. And if you calculate Slope with those values, without the future-peeking, you don't get the nice smooth Slope plots any more. The resulting Slope looks a lot more like the price.

Here's my "corrected" version of Paul's Slope, plotted next to Neo's Slope. Paul's Slope matched Neo's exactly before I made this change.

Slope.gif

So, Paul or or George (or John or Ringo ) or somebody, check me on this. Is calcPrevTrue() wrong as currently written, and the nice smooth Slope plots we've seen have been incorrect? Shouldn't calcPrevTrue( , , x) == calcTmaTrue( , , x+1)? Or Paul, am I misunderstanding what you're doing?

BTW we may be able to approach the nice smooth curves again by running it through an average. I notice that the corrected code is a few bars ahead of the original code, so the delay added by the smoothing might just put us back where we were with the future-peeking code.

Maybe that calcPrevTrue() was intended as smoothing? Strictly speaking it's not really future-peeking. It looks "one bar ahead" but it's starting out "one bar in the past" so it's only looking at the current bar. So it shouldn't change as the bar moves into the past.

[gaheitman]

That's the logic bug I suspected... I don't see why you'd want to do that. That's "future-peeking" that we've been trying to avoid with the "TMA" indis.

I can't speak to the validity of using it the way it is coded as far as the system goes. I've mostly missed the Slope train and am still catching up.

The purist in me doesn't ever want to use the close of the current bar in any calculation since the close isn't actually set until it's no longer the current bar. However, since we are using the current value of the current bar in the calculation of the slope, I don't have an issue using it in the calculation of the previous bar's TMA.

I believe it will cause a slight jump/drop in the value of the slope for the current bar as it transitions to being bar 1. If this jump is enough to make signals appear in the past that didn't exist in real-time or have real-time signals disappear, then it is a problem, but only so far as reviewing historical charts. Trading decisions would still only use data we know.

George

[Baluda]

The only difference I see is that calcPrevTrue() inits the dblSum and dblSumw to iClose( symbol, tf, inx ) * 20 and 20, but I don't understand why -- why include the inx bar in the Prev calculation??

Gary,

The inclusion of the current bar in the calculation of the TMA of the previous bar is the only difference between TMA Slope and LWMA Slope. It is the one factor that distinguishes TMA Slope from LWMA Slope.

The debate goes on forever I guess.

Paul

[NeoTrader]

Hi Gary,

I'd suspect there's a logic bug in there, but you and Neo's indicators produce the same results. He hasn't released his code so maybe he just "borrowed" your Slope code...

We both borrowed our Code from zznbrm, who was the initial developer of the slope as we both credited him also in our Indicator announcements and descriptions. My code is almost exactly the same as Paul's as his code is almost exactly the same as the code from zznbrm.

And Paul is correct with his statement that this one forward peeking bar is the main difference between TMA and LWMA and is also the reason why our slopes look smoother than yours..

So, Paul or or George (or John or Ringo )

I want to be Ringo...


happy weekend,

NeoTrader

-

[mobthehop]

mmhhh.....

and what does this normalization factor do? (pls scroll down about halfway, starting at "if ( eblnNormalize )"

Code: Select all

//+------------------------------------------------------------------+
//| calcTmaSlope()                                                   |
//+------------------------------------------------------------------+
double calcTmaSlope()
{
   // Calculate the current TMA
   double dblTma = iMAOnArray( gadblData, WHOLE_ARRAY, eintPeriod+1, 0, MODE_LWMA, 0 );
   
   // Calculate the previous TMA
   double dblSum  = (eintPeriod+1) * gadblData[1];
   double dblSumw = (eintPeriod+1);
   int jnx, knx;
 
   dblSum  += ( eintPeriod * gadblData[0] );
   dblSumw += eintPeriod;
         
   for ( jnx = 1, knx = eintPeriod; jnx <= eintPeriod; jnx++, knx-- )
   {
      dblSum  += ( knx * gadblData[jnx+1] );
      dblSumw += knx;
   }
   
   double dblPrev = ( dblSum / dblSumw );
   
   // Calculate the TMA Slope
   double dblSlope = ( dblTma - dblPrev ) / gdblTruePoint;
   
if ( eblnNormalize )
   {
      double dblAtr = iATR( Symbol(), gintTf, 100, 1 );
      int int15 = iBarShift( Symbol(), PERIOD_M15, iTime( Symbol(), gintTf, 0 ) );
      double dblAtr15 = iATR( Symbol(), PERIOD_M15, 100, int15+1 );
         
      if ( ( dblAtr > 0.0 ) && ( dblAtr15 > 0.0 ) ) 
      {      
         dblSlope *= ( dblAtr15 / dblAtr );
      }
   }
   
   return( dblSlope );
}

//+------------------------------------------------------------------+
//| genTruePoint()                                                   |
//+------------------------------------------------------------------+
double genTruePoint()
{
   double dblPoint;
         
   // Reset point value for 5 digit brokers
   switch( Digits )
   {
      case 5:
      case 4:     dblPoint = 0.0001;   break;
      case 3:
      case 2:     dblPoint = 0.01;     break;
      case 1:     dblPoint = 0.1;      break;
      case 0:     dblPoint = 1.0;      break;
      default:    dblPoint = 0.0001;
   }
   
   return( dblPoint );
}

And zznbrm does not use "include Sunday candle"

Cheers

[NeoTrader]

Hi mobthehop

and what does this normalization factor do? (pls scroll down about halfway, starting at "if ( eblnNormalize )"

This is not part of the standard tma or true calculation (at least not in this form). If I remember correct this code is from the Cristal ball version of zzbrnm and it is used to normalize the slope value to be put directly on the main chart screen in form of the lines (lanes) that he uses in that version to display the slope.

And zznbrm does not use "include Sunday candle"

correct...this was an addition of Paul...since there are some people who have Sunday candles which changed the values of the tmaslope of the Daily TF.

hope this helps,

happy Sunday,

NeoTrader

[garyfritz]

OK. So the original Slope code comes from zznbrm, and he had that factor in there for reasons unknown. Let's look at what that does...

calcTmaTrue( , , i) = 21 * Close + 20 * Close[i+1] + 19 * Close[i+2] + ... + 1 * Close[i+20]
calcTmaTrue( , , i+1) = 21 * Close[i+1] + 20 * Close[i+2] + 19 * Close[i+3] + ... + 1 * Close[i+21]
calcPrevTrue( , , i) = 20 * Close + 21 * Close[i+1] + 20 * Close[i+2] + ... + 1 * Close[i+21]

(And the division by the sum of weights, of course.)

So if I've got that right (check me, please!), calcPrevTrue has ONE MORE TERM than calcTmaTrue. calcPrevTrue(i) is identical to calcTmaTrue(i+1) except it adds the 20*Close term.

They also have different weights: calcTmaTrue's weight is 21 + 20 + 19 + ... + 1 = 231, calcPrevTrue's is 20 + 21 + 20 + 19 + ... + 1 = 251. The larger calcPrevTrue weight corrects for the extra term so they should end up in the same range.

When I looked at this before (not carefully enough!) I thought Slope was (TmaTrue - PrevTmaTrue) / ATR. Not counting the ATR division, that would be:

calcTmaTrue(i) - calcTmaTrue(i+1)
= 21 * Close + (20-21) * Close[i+1] + (19-20) * Close[i+2] + ... + (1-2) * Close[i+20] - 1 * Close[i+21]
= 21 * Close - Close[i+1] - Close[i+2] - ... - Close[i+20] - Close[i+21]

Meanwhile zznbrm's actual Slope that we've been using (not counting Paul's Sunday addition) is:

calcTmaTrue(i) - calcPrevTrue(i)
= (21-20) * Close + (20-21) * Close[i+1] + (19-20) * Close[i+2] + ... + 1 * Close[i+21]
= Close - Close[i+1] - Close[i+2] - ... - Close[i+20] - Close[i+21]

So, assuming I got my math right, the difference between (TmaTrue - PrevTmaTrue) / ATR and zznbrm's Slope is the first term: 21 * Close vs. 1 * Close. The simple (Tma - PrevTma) / ATR calculation weights the current bar MUCH heavier. That would explain why the simple calculation looks so much more like the price.

But I can't have my math right. The simple slope calc has one +21 * Close term and 21 -1 * Close terms, so it's centered around zero like we'd want. I tested the equation in Tradestation and it matches the standard TMA - PrevTMA way of calculating slope. But the zznbrm slope (by my equation above) has one +1 * Close term and 21 -1 * Close terms, so it's always negative, and a TS check confirms that. Where did I go wrong?

[gaheitman]

But I can't have my math right. The simple slope calc has one +21 * Close term and 21 -1 * Close terms, so it's centered around zero like we'd want. I tested the equation in Tradestation and it matches the standard TMA - PrevTMA way of calculating slope. But the zznbrm slope (by my equation above) has one +1 * Close term and 21 -1 * Close terms, so it's always negative, and a TS check confirms that. Where did I go wrong?

In the zznbrm slope, the two series have different divisors, so you can't simplify them the way you have shown. The first term is really

Code: Select all

(21 * Close[i])      (20 * Close[i])
--------------   -  -------------- 
      231                   251

which can't be simplified to Close.


George