Tick Replay & GetCurrentXXX()

[NJA_MC]

I am not sure I am doing something correctly. I am trying to access the CurrentAsk/Bid values within Tick Replay mode on the chart. But is seems like these values are both equal to the Input Value. This indicator is calling OnBarUpdate() on every Tick.

GetCurrentAsk(): 1873 GetCurrentBid(): 1873 Input[0]=1873
GetCurrentAsk(): 1873.25 GetCurrentBid(): 1873.25 Input[0]=1873.25
GetCurrentAsk(): 1873.25 GetCurrentBid(): 1873.25 Input[0]=1873.25
GetCurrentAsk(): 1873.25 GetCurrentBid(): 1873.25 Input[0]=1873.25
GetCurrentAsk(): 1873.5 GetCurrentBid(): 1873.5 Input[0]=1873.5
GetCurrentAsk(): 1873.5 GetCurrentBid(): 1873.5 Input[0]=1873.5

[NJA_MC]

Once LIVE data started up again when the market opened these functions performed as expected. This appears to be a bug in BETA3, I didn't check this on earlier version.

GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1860.75
GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1860.75
GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1860.75
GetCurrentAsk(): 1861.25 GetCurrentBid(): 1861 Input[0]=1861
GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1861
GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1861
GetCurrentAsk(): 1861 GetCurrentBid(): 1860.75 Input[0]=1861

[NinjaTrader_DaveI]

Hello,

This is to be expected with GetCurrentBid() and GetCurrentAsk() -- when processing historical data, the Close value will be substituted (the current value of Input on the current bar). To access historical Bid and Ask data, you can use AddDataSeries() while specifying MarketDataType.Ask or MarketDataType.Bid using the overload below:

AddDataSeries(string instrumentName, BarsPeriodType periodType, int period, MarketDataType marketDataType)

Then, calling Closes[][] on the added data series should give you historical Bid or Ask prices, depending on the MarketDataType used.

[NinjaTrader_DaveI]

One quick note for you -- For a less resource-intensive method of accomplishing this, you can also access the Bid and Ask prices via the MarketDataEventArgs object passed into OnMarketData(). You can then store that value in a variable accessible on OnBarUpdate() (or wherever else you need it).

We are going to be updating the NinjaTrader 8 Help Guide to clarify this further, but GetCurrentAsk() and GetCurrentBid() were always designed with the intention of being used on realtime data only.

[NJA_MC]

Hi David,

I see the note in the user guide now for this feature. I can just tell you that this issue with "Tick Replay" just doesn't make sense. I think this is going to cause manage confusion and disappointment. Probably even cause errors in strategy analysis, etc.

My understanding is that NT8 now carries the BID/ASK price at the tick level, I would expect these functions to also carry that expectation. Certainly for Bar & Price calculation, CLOSE might bet the best option.

This is going to cause more confusion and software complexity upon the user to properly handle Historical Tick Data differently than real-time tick data.

I would urge the development team to reconsider this current implementation.

[NinjaTrader_Matthew]

Thanks for the feedback. We discussed this throughout development, but it's just not possible to implement the market data object that GetCurrentBid/Ask use in real-time the same way historically. Remember we're dealing with tick data, which is synchronized with a bar which is NOT the same as the market data pointer that is used in real-time. Hence, there are concept problems with what to sync, and when to update, etc that were reviewed and ultimately had to drop. I just added a note to these methods documentation in the help guide to help further clarify and try to prevent any confusion.

[NJA_MC]

Hi Matthew,

Good to hear it was discussed, sorry to hear the decision. In the manual it should clearly state to not use this feature in any Indicator/Strategy which might rely on Tick Replay. The manual should point to the work-around example using the OnMarketData() with an example of implementation.

I do believe this is going to cause major frustration to users thinking that Tick replay will carry the proper Ask/Bid values to these functions. This is just my perspective as a users. It is just not intuitive that accessing Ask/Bid in this manor would not be valid during Tick Replay. You might even want to throw a warning if someone uses these features with "Tick Replay" enabled, they are going to get erroneous results and unless they go back and debug this from a HISTORICAL perspective, might live with the error and potential act upon that error.

Thanks for the feedback. We discussed this throughout development, but it's just not possible to implement the market data object that GetCurrentBid/Ask use in real-time the same way historically. Remember we're dealing with tick data, which is synchronized with a bar which is NOT the same as the market data pointer that is used in real-time. Hence, there are concept problems with what to sync, and when to update, etc that were reviewed and ultimately had to drop. I just added a note to these methods documentation in the help guide to help further clarify and try to prevent any confusion.

[NinjaTrader_Matthew]

Sure, I see your point - we'll add further clarification and examples in the help guide.

However we also should not be giving a false impression that "Current" bid ask data can be accessed historically, as anything you see in Tick Replay is the ask/bid at the time a trade went off and not a stream of ask/bid data. You can use the Bars.GetAsk()/GetBid() as well, but these are NOT the same as how GetCurrentAsk/Bid work in real-time.

[strategesis]

I would like to suggest that the documentation prominently include a section that lists and discusses any API methods or objects which won't work the same historically, historically when using tick replay, and/or in real time. Of course, if they won't work at all in some cases, that should also be documented.