Bars.GetOpen(CurrentBar+1) in Live Trading

[AlgoJason]

The way that NT backtest appears to work is that when the first tick comes along which is outside of a bar, then that bar is "closed" and OnBarUpdate() is called.

The data inside the bar, including the Close[0], is all out-of-date by at least 1 tick. Because the open of the "next" bar has already occurred.

Imagine that there are three ticks and that minute bars are being created.

TickNumber, Time
1, 14:00:00
2, 14:00:59
3, 15:00:00

In this case, when the third tick arrives, NT calls OnBarUpdate() and inside it Close[0].Time is 14:00:59. This is an out-of-date datapoint. The most up-to-date datapoint, which is most definitely NOT in the future, is tick number 3. There is no "look-ahead bias" in using this value.

Orders placed in OnBarUpdate() are actually filled at the price of the open of the next bar and not at Close[0]. This is correct because it is the most up-to-date data point.

The most up-to-date price is available in OnBarUpdate() through:

Bars.GetOpen(CurrentBar+1)

.

A "Zero Slippage, No Delay" simulation can therefore be achieved by doing something like this. Pseudo code:

var samplePrice = Bars.GetOpen(CurrentBar+1);
var position= GetPositionFromAlgorithm(samplePrice);
if(position > 0)
  EnterLong();
if(position) < 0)
  EnterShort();

In this way the NT fill price will be the same as the sample price.

Now, there is an old thread which discusses this point:

https://ww.ninjatrader.com/support/forum/showpost.php?p=481845&postcount=32

The thread heats up and is never finished. Let's ignore the emotion in that thread and let's discuss this "Bars.GetOpen(CurrentBar+1)" thing.

I would like to know from NT staff/developers what will happen in the event that the strategy code uses Bars.GetOpen(CurrentBar+1) in live-trading.

Is it the same?

I.e. OnBarUpdate() is called when the tick which opens the "next" bar has arrived and Bars.GetOpen(CurrentBar+1) will give you that most up-to-date tick?

This is the tick which should be used to generate signals. Not Close[0]. Or am I missing something?

[NinjaTrader_Jim]

Hello AlgoJason,

Welcome, and thanks for opening the thread.

Yes, the tick-through behavior is what signals the close of a bar. I'm aware of some discussions to try and work around this to get the most recent price on bar closes, but I am not sure what else I could tell you outside of what Product Management has already stated:

Although yes you can do what DavE suggested you must be careful since your working around how its intended to work and coding in 'look ahead' logic into your code. You obviously can't look ahead during realtime so I would not advise adding that code unless you understand what your getting into there in terms of having separate backtest logic vs realtime logic.

As to utilizing the bid/ask which you re-clarified is what your after this is something we have our list to consider looking into but not something we do currently or anytime in the near future.

-Brett

Since it is not an intended use of the software it wouldn't be something we will be able to research in a support inquiry. You should be able to test the behavior appropriately on a paper trading account, however. I would also encourage you to report your findings as well for others that want to experiment with their strategies.

If you would like us to submit a feature request for a supported means to fetch the most recent price in OnBarUpdate(), we could do that to track your interest. As I saw in the thread the feature requests did not address what DavE had proposed.

Please let me know if there is anything would like me to do to assist you further.

[AlgoJason]

Feature Request

If you would like us to submit a feature request for a supported means to fetch the most recent price in OnBarUpdate(), we could do that to track your interest.

That would be awesome. Please do create a Feature Request. It would be great to have a discussion of implications too.

[NinjaTrader_Jim]

Hello AlgoJason,

I've submitted the feature request on your behalf and I'll update with this post with the ticket ID when it becomes available.

EDIT: The feature request ticket ID is: SFT-2993

As with other feature requests, we cannot present an ETA as they are fulfilled based on the development team's schedule and priorities. Upon implementation the ticket ID can be found publicly on the Release Notes page of the help guide. I'll provide a link below.

Release Notes: https://ninjatrader.com/support/help...ease_notes.htm

Since using Bars.GetOpen(CurrentBar+1) is an unsupported use of the platform, I will leave any discussion open to other forum members that would like to share their experience. If an approach becomes supported in the future, any implications will be outlined in the help guide.

I'm happy to be of any additional help.

[koganam]

The way that NT backtest appears to work is that when the first tick comes along which is outside of a bar, then that bar is "closed" and OnBarUpdate() is called.

The data inside the bar, including the Close[0], is all out-of-date by at least 1 tick. Because the open of the "next" bar has already occurred.

Imagine that there are three ticks and that minute bars are being created.

TickNumber, Time
1, 14:00:00
2, 14:00:59
3, 15:00:00

In this case, when the third tick arrives, NT calls OnBarUpdate() and inside it Close[0].Time is 14:00:59. This is an out-of-date datapoint. The most up-to-date datapoint, which is most definitely NOT in the future, is tick number 3. There is no "look-ahead bias" in using this value.

Orders placed in OnBarUpdate() are actually filled at the price of the open of the next bar and not at Close[0]. This is correct because it is the most up-to-date data point.

The most up-to-date price is available in OnBarUpdate() through:

Bars.GetOpen(CurrentBar+1)

.

A "Zero Slippage, No Delay" simulation can therefore be achieved by doing something like this. Pseudo code:

var samplePrice = Bars.GetOpen(CurrentBar+1);
var position= GetPositionFromAlgorithm(samplePrice);
if(position > 0)
  EnterLong();
if(position) < 0)
  EnterShort();

In this way the NT fill price will be the same as the sample price.

Now, there is an old thread which discusses this point:

https://ww.ninjatrader.com/support/forum/showpost.php?p=481845&postcount=32

The thread heats up and is never finished. Let's ignore the emotion in that thread and let's discuss this "Bars.GetOpen(CurrentBar+1)" thing.

I would like to know from NT staff/developers what will happen in the event that the strategy code uses Bars.GetOpen(CurrentBar+1) in live-trading.

Is it the same?

I.e. OnBarUpdate() is called when the tick which opens the "next" bar has arrived and Bars.GetOpen(CurrentBar+1) will give you that most up-to-date tick?

This is the tick which should be used to generate signals. Not Close[0]. Or am I missing something?

What about the reality of the bid/ask spread?

[AlgoJason]

What about the reality of the bid/ask spread?

That is a great question. I do not have a solution to that problem right now. But using Close[0] instead of Bars.GetOpen(CurrentBar+1) still faces the same question: What about the reality of the bid/ask spread?

[koganam]

That is a great question. I do not have a solution to that problem right now. But using Close[0] instead of Bars.GetOpen(CurrentBar+1) still faces the same question: What about the reality of the bid/ask spread?

Examine the edge cases again, and you will see that in fact using Close[0] obviates the question of the bid/ask spread, whereas using Bars.GetOpen(CurrentBar+1) will have the problem of using an indeterminate real price in the case of a gap open, once you take the possible vagaries of the bid/ask spread into account.

[AlgoJason]

Apologies for late reply, I did not see your reply until now.

I definitely would not at this stage disagree with you on this issue re the spread. I will have to look into it.

One thing is probably going to be true of any viable trading strategy though: It should be able to generate a profit using Close[0].

AFAIK Close[0] is basically a 1-tick delay between sample and fill. That ought not make or break a viable non-HFT system.

[koganam]

Apologies for late reply, I did not see your reply until now.

I definitely would not at this stage disagree with you on this issue re the spread. I will have to look into it.

One thing is probably going to be true of any viable trading strategy though: It should be able to generate a profit using Close[0].

AFAIK Close[0] is basically a 1-tick delay between sample and fill. That ought not make or break a viable non-HFT system.

Pretty much the point that I have been trying to make, and getting insulted because I dare to say so. Not by you obviously.