Keltner Channel indicator rounding

[tradetree]

I was looking for a bug in my strategy, and so I dumped some data to excel and manually applied my own Keltner channel calculation to the data. I compared this to what was coming out of NT with my calls to the built-in function. I found a small rounding difference. So I reviewed the code from NT that is open for anyone to review in the Indicator directory, and it looked correct. In fact, it logically matched the steps I was doing in my excel spreadsheet, but the data output did not match.

I then went into the debugger to figure out what I had done wrong in my spreadsheet even though I thought I was doing the same operations. When I stepped into the NT indicator source code, I found out that there is optimized code to cache previous data used in the Keltner channel calculation, and thus speed processing of the new values. This was all very clever and understandable, however there was a resulting minor rounding difference.
I could then not rely on the exact reconstruction of a series of events in my strategy. In other words, it rendered post-event reconstruction impossible, or much harder.

What I have done instead is to create my own Keltner channel that is exactly the formula, instead of just very close. Now I can always reconstruct events exactly. I found the rounding difference was enough to affect the Keltner parameters I use.

I was hoping NT could comment on this, and explain how this caching mechanism is intended to work and how they preserve precision? Caching works well with SMA calculations, and I see how NT does this without any rounding impact. But I think the Keltner Channel is allowing a small error by using caching.

[NinjaTrader_RyanM1]

Thank you for your feedback and report. I will forward as a suggestion to our development team.

[NinjaTrader_JoshP]

tradetree,

The SMA indicator uses prior values for future calculations instead of recalculating every single data point for performance purposes. A caveat of this approach is that if you go back and change some of the input data points for calculations, it will not necessarily be reflected in the SMA calculation which is still using prior SMA values. Rounding is not related.

When you bring it over into the Keltner Channel the same applies to it since it relies on the SMA indicator. The Keltner Channel then does some arithmetic on the SMA value which can run into some floating-point math concerns. Please see here for more information: http://www.ninjatrader.com/support/f...ead.php?t=3929

[tradetree]

Yes, I am not concerned with the SMA. That is bit-exact. I think the keltner calculations, that are more complex are the ones that run into the floating point issues. I think my solution is the right one, where I have my own keltner function, as an exact comparison is more important to me than performance.

[tradetree]

In addition, here is the background as to how this came up. I found that my strategy runs differently in real-time during the day than back-testing or even MarketReplay. I have had trades take place that I know should not. I then go to debug my strategy, and find out that it is not reproducible even though I'm using the same data that produced the trade in the first place. Sounds strange, I know, but how can I gain confidence in the system if it has a mind of its own? Now I fully expected and thought it has to do with my strategy, and it might. But how can I find it when the calculations are not bit-exact in an important calculation? That is my dilemma.

So now I have coded up a logging system that runs in the strategy and logs all the internals and data during the day as the strategy runs. If or when a bad trade takes place I should be able to reconstruct the problem. What will be interesting is if there is no longer any bad trades! If that is the case then I'll have to believe the NT Keltner optimizations have an accumulative error over time. Can't say that for right now, but I'll see how it runs from here.

[koganam]

In addition, here is the background as to how this came up. I found that my strategy runs differently in real-time during the day than back-testing or even MarketReplay. I have had trades take place that I know should not. I then go to debug my strategy, and find out that it is not reproducible even though I'm using the same data that produced the trade in the first place. Sounds strange, I know, but how can I gain confidence in the system if it has a mind of its own? Now I fully expected and thought it has to do with my strategy, and it might. But how can I find it when the calculations are not bit-exact in an important calculation? That is my dilemma.

So now I have coded up a logging system that runs in the strategy and logs all the internals and data during the day as the strategy runs. If or when a bad trade takes place I should be able to reconstruct the problem. What will be interesting is if there is no longer any bad trades! If that is the case then I'll have to believe the NT Keltner optimizations have an accumulative error over time. Can't say that for right now, but I'll see how it runs from here.

Have you thought of using Round2TickSize() on your values in the Strategy. After all, a Keltner value of 58.25462799 makes no sense when prices can only read 58.25, for example.

[tradetree]

Good idea. I'll add that in, but I think I'll add it to my version so that I have full control. Thanks.

[tradetree]

I found the real problem between historical strategy running and real-time strategy running. The data for the same date/time/instrument/period are different! No wonder I've been going out of my mind.

How is this possible? I was getting ready to release my strategy to a broker for live trading, and this is a major show-stopper. So let me be very specific:

I log every single bar as it comes in during the day to a file. Here is a line from the log for yesterday:
Live Instrument: YG 06-11, 15 Minute. Bar Time: 3/10/2011 12:31:00 PM Close: 1409 Bar: 55417

Here is the same log line when I ran it today so the bars are historical rather than live:
Historical Instrument: YG 06-11, 15 Minute. Bar Time: 3/10/2011 12:31:00 PM Close: 1407.1 Bar: 55330

See how the Close for the same bar is 1409 on one and 1407.1 on the other?

Here is the line in code that produces this file output:
string live = Historical ? "Historical": "Live";
string dump = live + " Instrument: " + Instrument.FullName + ", " + BarsPeriod.Value + " " + BarsPeriod.Id + " Bar Time: " + Time[0] + " Close: " + Close[0] + " Bar: " + CurrentBar;
fStream.WriteLine( dump );

Now to be clear, the CurrentBar numbers do not match, but that is expected. When Time[0] match, then the Close[0] values should also match whether live or historical. Otherwise, you will be out of sync with your strategy every day! The strategy calculates different positions based on live and historical data, which destroys the possibility of keeping synchronized or even back-testing and getting the same results.

[koganam]

That sounds like a problem with the data provider. If by any chance you recorded the data with the replay connection, what does the bar data say there?

[NinjaTrader_RyanM1]

We expect there to be differences between real time and historical data. Please see the following link > Understanding why a chart can look different after reloading historical data from the server

http://www.ninjatrader.com/support/helpGuides/nt7/how_bars_are_built.htm

[tradetree]

Two things:
1) I do not believe the difference I'm seeing can be explained by one or two ticks.
2) If this is the case, then how can you develop strategies that are consistent? I found this because during the day there was a trade and when I re-enabled the strategy the next day the trade was gone. That means that instead of being long 1, I was flat.

My thinking is that I'm going to do my own data logging, and when I reenable a strategy I'm going to process my own recorded historical data. The built-in data capture only is used for MarketReplay. I don't need this for MarketReplay but for the actual running of my strategy. I need the same data leading up to the real time bars, as I have many people using my signals. They can't be told, "oh, yesterday's trade didn't really happen."