Calculate On Bar Close Considerations

[molecool]

So I have a new strategy that runs via 'calculate on bar close' set to false. It's done in the code as well as in the strategy settings - I take it the coded one has precedence?

More importantly I'm noticing different entry behavior on historic data than on live data. On the live side it's doing what it's supposed to be doing, which is enter immediately at the open of my setup candle (the one that's providing the entry trigger). It does not wait for the close of that candle.

On historic data however it waits out the setup candle and then enters at the open of the next candle - as if I had it set 'calculate on bar close' to true. I can understand how that could be in certain scenarios if there are complex entry rules. However, the setup candle (0) in my case checks some rules involving the two prior candles (1 and 2) and then is supposed to enter immediately. And that's what it does on the live side. But not with the historic data - there it waits until the current candle has expired.

I have been working with NT for years but never encountered that as my strategies were normally running on closed candles. I guess I could simulate the right behavior by having the entry be done one candle earlier at its very end. But that then would change the live behavior.

I'm in a bit in a pinch here - what's the best way to approach this? I would love to backtest this strategy but right now the historic entries are all wrong. As a sidenote - once the live data took a proper entry it stays in NinjaTrader as a correct entry. That's the upside but it doesn't help me with symbols I have not run live against this strategy

Hope all this makes sense. Any input would be much appreciated.

[NinjaTrader_Lance]

Hello,

So I have a new strategy that runs via 'calculate on bar close' set to false. It's done in the code as well as in the strategy settings - I take it the coded one has precedence?

The GUI will take precedence

More importantly I'm noticing different entry behavior on historic data than on live data. On the live side it's doing what it's supposed to be doing, which is enter immediately at the open of my setup candle (the one that's providing the entry trigger). It does not wait for the close of that candle.

On historic data however it waits out the setup candle and then enters at the open of the next candle - as if I had it set 'calculate on bar close' to true. I can understand how that could be in certain scenarios if there are complex entry rules. However, the setup candle (0) in my case checks some rules involving the two prior candles (1 and 2) and then is supposed to enter immediately. And that's what it does on the live side. But not with the historic data - there it waits until the current candle has expired.

I have been working with NT for years but never encountered that as my strategies were normally running on closed candles. I guess I could simulate the right behavior by having the entry be done one candle earlier at its very end. But that then would change the live behavior.

I'm in a bit in a pinch here - what's the best way to approach this? I would love to backtest this strategy but right now the historic entries are all wrong. As a sidenote - once the live data took a proper entry it stays in NinjaTrader as a correct entry. That's the upside but it doesn't help me with symbols I have not run live against this strategy

Hope all this makes sense. Any input would be much appreciated.

When backtesting COBC is ALWAYS set to true regardless of the hard-coded or GUI settings.

If you need to perform backtesting with added granularity you need to setup a multi-series script such that it would run on a tick chart but calculate off of the desired time frame

For multi-series guide: http://www.ninjatrader.com/support/h...nstruments.htm

Example of Multi-granularity backtesting: http://www.ninjatrader.com/support/f...ead.php?t=6652

This example takes a higher time frame as the primary and then adds a lower timeframe to it. Some people prefer to handle it differently and make the smallest time frame the primary. I recommend trying both methods out and seeing what better first your testing.

[molecool]

If you need to perform backtesting with added granularity you need to setup a multi-series script such that it would run on a tick chart but calculate off of the desired time frame

For multi-series guide: http://www.ninjatrader.com/support/h...nstruments.htm

Example of Multi-granularity backtesting: http://www.ninjatrader.com/support/f...ead.php?t=6652

This example takes a higher time frame as the primary and then adds a lower timeframe to it. Some people prefer to handle it differently and make the smallest time frame the primary. I recommend trying both methods out and seeing what better first your testing.

Thanks for that - this explains quite a few things. Yes, I have used multi-timeframe strategies in the past and now how to tame them. However this adds another layer of complexity to my strategy which I have not anticipated (and which I would prefer to avoid frankly).

Alas, do you think I may run into problems running the existing strategy in a live environment? Does it make sense to pursue a multi-timeframe strategy only for back testing?

[NinjaTrader_Lance]

If you're strategy requires COBC = false then your best options for testing will be through Market Replay and/or letting it run on a sim account with a live data feed.

In case you aren't familiar with using market replay: http://www.ninjatrader.com/support/h...ket_replay.htm

Please let me know if I can be of further assistance.

[koganam]

Thanks for that - this explains quite a few things. Yes, I have used multi-timeframe strategies in the past and now how to tame them. However this adds another layer of complexity to my strategy which I have not anticipated (and which I would prefer to avoid frankly).

Alas, do you think I may run into problems running the existing strategy in a live environment? Does it make sense to pursue a multi-timeframe strategy only for back testing?

For Backtesting alone, probably not; for Optimizing, most assuredly.