Have they fixed Renko backtesting?

[scotpip]

Hi

I've always liked the look of NT, but we mainly trade Renko and the last time I reviewed our choice of platform I was put off by this thread about a show-stopping bug in Renko backtesting.

http://ninjatrader.com/support/forum...ad.php?t=49420

Essentially, the backtester gives seriously incorrect results for any entry on a reversal bar. If you read the thread you'll see that customers proposed a simple solution which was rejected by the company. Instead they proposed that Renko users should backtest with tick-level data. As was pointed out at the time, this would slow down backtesting by orders of magnitude and would be impractical for large data sets.

So my question is, have they had a change of heart? Does the current release enable the correct backtesting of Renko-based strategies without resorting to tick data?

[bltdavid]

Have you tried using UniRenko in place of Renko?

[bltdavid]

Does the current release enable the correct backtesting of Renko-based strategies without resorting to tick data?

This question doesn't make a lot of sense to me.

Renko bars, by definition, need to be built from Tick data.

[NinjaTrader_PatrickH]

Hello sctopip,

Thank you for your post.

Backtest fills are determined based on 4 data points; the Open, High, Low, and Close of a bar. This is because that is the only information that is available to a historical bar and thus in backtesting.

This provides additional limitations with Renko Bars as they redraw the "open" of the bar after the bar has formed. Because renko bars are formed based on price movement, prices that were traded at in real time can often be cut off. When the backtest is run over these bars it will have no way of knowing if an order placed within a few ticks of a bar would have been filled.

This is not limited to NinjaTrader alone, this is limited to all Historical Data.

You can look to use items such as Market Replay to backtest bar types that need to build on intra-bar movements: http://ninjatrader.com/support/helpG...connection.htm

[scotpip]

This question doesn't make a lot of sense to me.

Renko bars, by definition, need to be built from Tick data.

bltdavid - of course all bars are ultimately derived from ticks, but most backtest platforms run on pre-synthesised bars. This is because there can be thousands of ticks per bar, so running on premade bars will be thousands of times faster. If your style of trading only generates signals on bar close and open, this should give accurate results without having to process every tick. My question is about running backtests in NT with pre-synthesised Renko bars.

[scotpip]

Thanks for responding. I have the same problem as the customers in the previous thread that I quoted, in that I simply can't make sense of your answer.

I have written my own Renko implementation for building bars from ticks, and I have also written a bare-bones Renko backtester, so I'm pretty confident of my ground.

As you say, the next open is not known at the time of the close, as it will depend on whether the next bar is a continuation or a reversal.

However this presents no problem at all if entries can be calculated on the bar close.

The issue, as I understand it from the previous thread, is that you have decided to hard-code the entry on the opening of the next bar, presumably to allow for slippage. So the entry price will be one bar out on a reversal bar. This means that backtesting will not work correctly for customers using price-based bars. If you calculated price bar entries from the close and not from the open, the problem would be solved.

But I take it from your reply that this change is not going to happen, even though, as others have pointed out, it would surely be relatively easy to make. It seems strange that you should make a technical choice that prevents a whole class of customers from using your product. If you decide to change your minds, please let me know.

[birdjaguar]

Even with renko entries on the open, my backtesting using Parabolic SAR still finds the entries and exits to backtest one bar late. In other words, the entry in the backtest does not occur on the open of the next bar. It occurs on the bar after that. And this is not usually a reversal bar because PSAR entries are mostly on momentum.