Counter intuitive time stamps

[NinjaTrader_JoshP]

Thank you Harry. We were able to reproduce and will get back to you with what we find at a later point in time.

[Harry]

Thank you Harry. We were able to reproduce and will get back to you with what we find at a later point in time.

Thanks for confirming the problem.

[Harry]

Bug in Bars.Session.GetNextBeginEnd()

I just discovered another Ninjatrader bug, which is related to this problem.

If you have a tick, range, Renko or volume chart, and the first bar of a session has the time stamp of the session begin, the NinjaScript method Bars.Session.GetNextBeginEnd() does not return the correct session start, but the start time of the prior session.

To reproduce, use a one tick chart and apply the indicator attached.

For example, for ES use a double session template and look for a bar that closes at 8:30 Central Time, but belongs to the new session. For this bar GetNextBeginEnd() will find a session start of 15:30 prior day instead of the correct current session start.

The counterintuitive logic for tick bars has made its victims among the NT development staff.

[NinjaTrader_JoshP]

Hi Harry,

I sent you an email on what I think might be the same issue being discussed by your post here? Please let me know if it is different. The email I sent was in regards to minute bars though. Thanks.

[Harry]

Hi Harry,

I sent you an email on what I think might be the same issue being discussed by your post here? Please let me know if it is different. The email I sent was in regards to minute bars though. Thanks.

Thanks Josh, have answered your mail.

[Harry]

One bug fixed, the other bug not fixed with NT 7.0.1000.5

As far as I have tested this first bug was removed with release NT 7.0.1000.5. So there are no more multiple first bars of session. However, the method GetNextBeginEnd() is still flawed and will return a false session start time under the conditions specified below.

The data request range was 3 days. I am always in mode MergeBackAdjusted.

I am now offline and back on my main machine. Very strange as the chart that I have opened shows

-> only one session bar at the open on May 28 (chart 1)
-> but 8 one bar sessions at the open on May 27 (chart 2)
-> and 22 one bar sessions at the open on May 26 (chart 3)

This is the same chart, I just scrolled horizontally, and in one case every bar with the time stamp 15:30:00 is qualified as first bar of session and in the other cases it is not. Chart 1 is correct and this is inconsistent with charts 2 and 3.

[NinjaTrader_Dierk]

Josh, will follow up latest early next week with details (if needed). For now I suggest to take a look at #4448 of the release notes which points you to a new GetNextBeginEnd() signature designed specifically to meet your request.

Thanks

[Harry]

Josh, will follow up latest early next week with details (if needed). For now I suggest to take a look at #4448 of the release notes which points you to a new GetNextBeginEnd() signature designed specifically to meet your request.

Thanks

I don't understand what it means. GetNextBeginEnd() returns false values on single DataSeries tick charts under defined conditions, so in my opinion this is a bug that should be removed.

I have not made a special request, my special request was simply the idea that GetNextBeginEnd() returns correct values and not something different.

[Harry]

I have since discovered the new overload and tried to use it to repair some of my indicators.

The problem is that the original syntax of GetNextBeginEnd() allowed to use it outside of OnBarUpDate(). In particular I have used it

-> in PlotOverride
-> in GetLastBarSessionDate()

As the new overload requires a parameter int barsAgo, it can only be used within OnBarUpdate(). How can I access session start and end time of a bar within Plot Override or an external method such as GetLastBarSessionDate()?

[Harry]

Suggestion for Improvement

Finally the problem with GetNextBeginEnd() is not so difficult. The overload which has been created works fine but cannot be applied outside of OnBarUpdate() as it uses a parameter int BarsAgo.

So in any case a parameter Bars bars is needed. But then it would have been simpler to produce a signature that just adds the Bars bars parameter to the method as it exists, the syntax could look like this:

Bars.Session.GetNextBeginEnd(Bars bars, DateTime time, out DateTime sessionBegin, out DateTime sessionEnd).

Finally, the problem is relatively easy to correct. It appears for all bars built from ticks for those bars that have a timestamp equal to the session start. So if you add 1 second to all timestamps of bars built form ticks before calculatin sessionBegin and sessionEnd the problem is solved.

For example, I can solve the problem myself, if I replace the indicator code

Bars.Session.GetNextBeginEnd(Time[0], out sessionBegin, out sessionEnd);

with

if(Bars.BarsType.BuiltFrom == PeriodType.Tick)
	Bars.Session.GetNextBeginEnd(Time[0].AddSeconds(1), out sessionBegin, out sessionEnd);
else
	Bars.Session.GetNextBeginEnd(Time[0], out sessionBegin, out sessionEnd);

But it is always painful to code around an imperfect method. Can't it be hardcoded directly into the method that it adds 1 second for all bars built from tickbars?

[NinjaTrader_JoshP]

Harry,

What issue are you running into with the new signature in Plot()? It would work in the same manner as doing something like Close[0] or Open[0] in Plot() does. The [0] would be the last bar on the visible range of the chart and not the last bar of the chart. For GetNextBeginEnd(), the int barsAgo would work in the same manner as [0] did. I have attached a reference sample demonstrating how it works in a custom method and the Plot() method. Please clarify what issue you are having with it in either. Thank you.

On the screenshots (1st = first bar of session, 2nd = second bar of session):
Value on price panel = new signature called from custom method
Top values on indicator panel = sessionBegin new signature from Plot then old signature from Plot
Bottom values on indicator panel = sessionEnd new signature from Plot then old signature from Plot

The idea of the new method is to simply have a signature that works like how Bar series work. What you are asking for is almost a hybrid bars vs. timestamp mode which I feel might be a bit confusing. What we have provided is a very distinct line between the two. The old signature is timestamp driven. The new signature is bars driven. User can choose whichever one they feel is appropriate for their needs.

[Harry]

Josh,

thank you for your detailed answer, I will test it on my side and come back afterwards.

[Harry]

Hi Josh,

typically if I use a method within Plot I try to code it in a way that it also works, if I scroll back horizontally. This is what users of NinjaTrader expect! They do not want to get a different picture when scrolling forward as compared to scrolling backward.

If I apply the PlotTest1, it will only work, if I scroll forwards, but not if I scroll backwards.

A good illustration for the problem is the Linear Regression Indicator. If I use the NinjaTrader default indicator, it simply sticks at last bar loaded, but will not move to display the channel for the last bar shown on the chart.

So I have coded a modified version of the Linear Regression indicator that behaves correctly, as it does not reference in barsAgo, but calculates the regression channel for the last bar shown on the chart.

The snapshots below show what happens, if you scroll a chart backward with the two linear regression channels.

For this reason, if I use Plot Override, I never ever reference the current bar. An expression such as Time[0] cannot be used within Plot Override, because otherwise the Plot will show a different picture, if you scroll forward compared to the picture that it shows, if you scroll back again.

Instead of Time[0], you would always use the bartime of the last bar painted, to get the correct results. Therefore a method that uses int barsAgo as a parameter should not be used within Plot Override().

For illustration purposes, I have attached 3 snapshots of the Linear Regression Indicator.

[NinjaTrader_JoshP]

Harry,

What you have described for the scrolling backwards and forwards is simply how any and all [] indexing works in the Plot method. This is consistent behavior for everything like Time, Close, High, GetNextBeginEnd, etc.

For this reason, people who are programming in Plot and wish for values to be shown of the last bar being painted need to apply an index offset to accommodate for this in their [] indexes.

int diff = CurrentBar - LastBarIndexPainted;
graphcs.DrawString(Close[diff].ToString(), textFont, textBrush, bounds.X + 10, bounds.Y + 50, stringFormat);

Similarly when using GetNextBeginEnd, you would just do something like:

Bars.Session.GetNextBeginEnd(BarsArray[0], barsAgo + diff, out sessionBegin, out sessionEnd)

Please find the attached sample that demonstrates this concept. Basically "CurrentBar - LastBarIndexPainted" is equivalent to the [] index for the last visible bar on the chart. You can offset it further as you see fit from that point.

[Harry]

Hi Josh,

that makes sense and should solve my problem. I simply did not have the idea to introduce that offset, although is is quite simple.

Sometimes it is difficult to see the forest, if there are lots of trees. I will proceed to modify some 15 indicators now, it should not be a problem. I will report the results.

Thank you again for your help!