Strategy Analyzer skips last bar

[MojoJojo]

Hello NinjaTrader support,

during testing it has come to my attention that NT excludes the last bar in test runs(optimizer & backtest)

        protected override void OnBarUpdate()
        {
            if (CurrentBars[0] > Bars.Count - 5) {
                Print(Times[0][0] + " " + CurrentBars[0] + " " + Bars.Count);
            }
        }

Output is

03/06/2020 15:56:51 163705 163709
03/06/2020 16:00:57 163706 163709
03/06/2020 16:12:47 163707 163709

In most cases if not nearly all that's not a big deal but I'll have to take evasive measures in State.Terminate because of it.

NT version is: 8.0.22.0

[NinjaTrader_Jesse]

Hello MojoJojo,

The Bars.Count is always going to be greater than the CurrentBar. You can see this as either Count -1 or Count -2 depending on the calculation mode in use. https://ninjatrader.com/support/help.../nt8/count.htm

Count is a count starting at 1, CurrentBar is an index starting at 0 so they are 1 off simply from that difference when you have 1 element. We would only see Count -1 in realtime when the building bar is being included otherwise what you are seeing is normal with -2 in historical data. If what you are doing relies on the count you would need to account for those changes with the count.




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

[MojoJojo]

Hello Jesse,

thank you for explanation, you are correct that the count aka length of an array or a collection is always greater than the element index. However the last element is n - 1 and not n - 2 unless there have been changes in software development I have not been privy to. So I should have gotten 4 lines of output an not 3 in my example.

If the bar didn't exist how come NT exits my position at a time later than a bar than what the last bar that is accessible to me via CurrentBar but Bars.Get gives me the data.
NT skips one OnBarUpdate, this might be minor but it would be good form to investigate and fix the problem. It's easy to replicate, the only variables I can think of is the custom bars I am using(but bar is contained in Bars) or the NT version.

[NinjaTrader_Jesse]

Hello MojoJojo,

The Count is specific to NinjaScript here, this is not like an array count.

If the bar didn't exist how come NT exits my position at a time later than a bar than what the last bar that is accessible to me via CurrentBar but Bars.Get gives me the data.
NT skips one OnBarUpdate, this might be minor but it would be good form to investigate and fix the problem. It's easy to replicate, the only variables I can think of is the custom bars I am using(but bar is contained in Bars) or the NT version.

You will need to provide a more concise description here, I am having trouble understanding what you are referring to with this description.

In any case there is no problem here with the Count and what you observed. What you are seeing is normal and expected.

The value of the count changes depending on the Calculate setting being used and also is affected by TickReplay where the count is not known ahead of time. If your logic relies on using the Count in some way you will generally have a few conditions based on the count being -1 or -2 and also could use the Calculate property to determine which subtraction to use.



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

[MojoJojo]

Hello Jesse,

I am sorry that I am not eloquent enough to get my point across but I will give you a chance to shine here and explain to me the following result and why it doesn't raise an exception.

        protected override void OnBarUpdate()
        {
            if (CurrentBars[0] > Bars.Count - 5) {
                Print(Times[0][0] + " " + CurrentBars[0] + " " + Bars.GetTime(CurrentBars[0] + 1));
            }
        }

result

03/06/2020 15:56:51 163705 03/06/2020 16:00:57
03/06/2020 16:00:57 163706 03/06/2020 16:12:47
03/06/2020 16:12:47 163707 03/06/2020 16:14:54

[NinjaTrader_Jesse]

Hello MojoJojo,

I am not sure what you are expecting to be an error here, why should this raise an exception?

The current bar was greater than the count minus 5 so you printed the values of 0 BarsAgo at that time. You also used GetTime to specify an index of a bar to look at a future bar, keep in mind that would only work for historical data and would generally only be used to test something like the next bar price for historical fill examination. You generally would never reference future data because it hasn't happened yet.



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

[MojoJojo]

Hello Jesse,

alright whatever, I don't mind that for you it's good enough that you in a backtest the OnBarUpdate isn't invoked for the last bar and that a data series runs from the first bar to the second last.

It won't make much of a difference but it certainly isn't expected behavior, maybe I'm just picky.

[NT-Roland]

Hi MojoJojo,
I stumbled over the exact same thing when trying to do my own Tax calculations in Ninja up to and including the very last trade of a backtest.
It appears as if the last (accessible) bar of every backtest is (CurrentBar == Bars.Count -2). This gives me at least something close to the end result, but is not spot on.
I don't really understand this restriction. The data for and of the last bar / trade must be there. Otherwise, NinjaTrader wouldn't be able to show the correct PnL of the very last trade in the Strategy Analyzer (even using the close of such candle to calculate it, if exit on session close is enabled). Charting wouldn't be possible either.
However, NinjaTrader doesn't seem to enable access to this data (for whatever reason). At least, I wouldn't know which code snippet could do the trick in NT8.
NT-Roland

[MojoJojo]

Hi Roland,

including a tax calculation in a backtest is an interesting application.
Based on the information I've received, it's also not clear to me either why NT doesn't invoke OnBarUpdate for the last bar. I can think of some reasons like that users should not be able to create positions on the last bar, but basically all that applies to each session end and is already handled.

My personal way of dealing with the situation is to finalize my calculations in State.Terminate. Bars.GetClose(Bars.Count - 1) etc. should still be callable there but I am not certain because I'm using my own data access layer. It's inconvenient though having to write extra code.

[NT-Roland]

Hi MojoJojo,
Two things are certain: Death and Taxes :-). Without Taxes, NinjaTrader backtest results are just fancy power point dollars, unless you are resident in one of the very few tax locations worldwide imposing little to no Taxes on trading. To my knowledge, the US is not one of those tax havens :-). I'm therefore somewhat surprised that this is not (optionally) accounted for.
Since I want to see what really happens in the long run, I coded this myself.
I will give your State.Terminate idea a shot. Thx.
NT-Roland

[MojoJojo]

Hi NT-Roland ,

Taxes are important, however people on the day trading path are lucky that they will most likely never have to deal will handing a portion of their profits to the tax man.
Law makers keep live interesting by having more or less obscure tax codes, and incorporating such accounting for all the places in world would be a bit of a challenge.
However it's great that you are thinking ahead. If I ever go live I'll have to do the same but it's to complicated with a flat tax country.

[NT-Roland]

Taxes are important, however people on the day trading path are lucky that they will most likely never have to deal will handing a portion of their profits to the tax man.

Really? Which countries do you have in mind? I'm not expecting a fully blown tax calculator for all potential alternatives around the world, but I'm more than surprised that Ninja does not even offer accounting for a flat tax rate to be entered by the user (e.g. 25%) for annual tax calcs.
NT-Roland

[MojoJojo]

I was rather thinking along the lines that overcoming randomness, spread, slippage, commissions and other running costs, poses a formidable enough challenge for the average day trader to not realize profits, maybe not over a short time period though. Which isn't a problem as long as it's treated as a hobby.
Factoring in taxes is a valid consideration in many cases, e.g. systems that reinvest profits or portfolios that are not only buy and hold.

Imo if NT added a tax calculation they'd have to do so with a huge disclaimer because in most people's cases it would be too simplistic or not apply at all.