Request: rename CurrentBar -> to LastBarNumber

[misova]

I would suggest rename existing convention of "CurrentBar" into "LastBarNumber".

Summary of problems with CurrentBar

1. people tends to think it is a Bar object, but in reality it is integer with bar-number
2. word "current" does not expresses clearly, that it simply always is the "last" bar in dataseries.
3. word "current" is misleading, because is often not very "current" from perspective of current-present-time (as DateTime.Now). The last daily bar can be very old from perspective of current-time - it can be for example 21 hours old. Referencing this
   with notion of "current" bar is not the most happy. But referencing it as "last" bar
   is very exact and clear in every case.

The ratio behind the idea:
We all see (visually in 1D space )the "bar series on chart" as series of individual bars ordered by time.

The first bar in this series is the left-most bar.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
The last bar in this series is the right-most bar.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

The sense of ordinal dimensionality is better expressed in dimensional words "first" bar / "last" bar, compared to the "current" bar, which is used now. The natural intuitiion of these words is better, because we all imagine bars in horizontal 1D space.

I would say it is more logical and easier to tell users - this is the "last" bar - and everybody understands which one it is = the really last one in the series.
Otherwise, I explain to my friends - you know, the "CurrentBar" really means the "last" bar in the dataseries.
And I have to also add - you know, it is called "CurrentBar", but in reality, it is not a "Bar" object. It is just the bar-number of the "last" bar. This is often their best moment, when they get the simple idea.

When we have to explain and "translate" such a basic and fundamental name into something more easily understandable, something is not OK about naming of this property.


To prevent this misunderstandings and explanation what "CurrentBar" really means, I would prefer very clear and exact name.
Lets replace CurrentBar -> for clear LastBarNumber.



Benefits of better name LastBarNumber:

1. it is clear, that is is number and not a Bar object
2. it is clear, that is is bar-number (as and opposite to bar-index)
3. it is clear for everyone, that it is the last one (and logically rightmost) bar they have on chart.
4. They don't need to mentally evaluate the word "current". It is really not important
   to them, if it is current or not current. They simply want the last bar, that's all.

Generally, it is easier, simpler and more intuitive to think in ordinal dimension - first / last bar,
than to think from time-perspective - current / oldest bar.



Example from C#
The logic is the same as in C# List LINQ extensions - there is a First element and the Last element.
When there would be something like Current element - then API users would have many questions (as they have now with CurrentBar), what does it really mean?
And we would explain: Dear users, it is so easy - think about Current element is the "Last" element. It is completely the same.

[sledge]

I fully see were you are coming from on this one...

But there is an element of time you are missing out on.. Current implies right now, at this moment of time.

[misova]

I fully see were you are coming from on this one...

But there is an element of time you are missing out on.. Current implies right now, at this moment of time.

Yes, I understand that...
Problem is, that there are so many people, who do not

I don't like how easily this simple idea is broken in mind of API users, especially beginners.
There are many logical directions (I summarized the below, why users are confused),
where this simple thing can be misunderstood easily and very naturally.

[koganam]

Yes, I understand that...
Problem is, that there are so many people, who do not

I don't like how easily this simple idea is broken in mind of API users, especially beginners.
There are many logical directions (I summarized the below, why users are confused),
where this simple thing can be misunderstood easily and very naturally.

CurrentBar is not necessarily the LastBar (whether or not we append the "Number" string). The CurrentBar is the bar that is being currently processed by the code, and there are occasions when the bars must be serially processed, such as, on first load of the indicator. In that case, CurrentBar does start from zero and progress serially to the LastBar.

I am inclined to agree that the name, ending in "Bar", could be a bit confusing, but at best renaming it would have to be to rename it to CurrentBarNumber. It is probably not critical, IMHO, but appending the "Number" certainly does make it clear that we are referencing a number, not a bar.

[misova]

CurrentBar is not necessarily the LastBar (whether or not we append the "Number" string). The CurrentBar is the bar that is being currently processed by the code, and there are occasions when the bars must be serially processed, such as, on first load of the indicator. In that case, CurrentBar does start from zero and progress serially to the LastBar.

I am inclined to agree that the name, ending in "Bar" could be a bit confusing, but at best renaming it would have to be to rename it to CurrentBarNumber. It is probably not critical, IMHO, but appending the "Number" certainly does make it clear that we are referencing a number, not a bar.

Thanx koganam, good points.

To the:CurrentBar is not necessarily the LastBar.

Yes, you are right - the bars are processed serially (not in parallel), so there can be more new bars waiting to be processed if computer is slower let's say for example. In this case, that "current" bar really does not have to be the "last" bar known in dataseries, because there are more hidden bars waiting to be processed.

I agree with that completely, but I would say, this is exact view from technical perspective how bars are processed internally.
But from perspective of developer of trading strategies - there is nothing like "hidden bars waiting to be processed in NT internals". What we have - is only the "last" and rightmost bar that is put for processing now. That's is all we can do. For us developers it is the same, as such "future waiting" bars really do not exist, because we are not and probably should not be aware of them.
We can do nothing with the future bars queued to be processed in NT internals.
That's why I do not find it useful to think about with real level of technical complexity, that is not exposed to the user and public API.

From perspective of user of public API, all we have in every point of time is only the "last" bar, everything other are just NT internals (including queued unprocessed bars).

I would prefer, that public PI should expose things from perspective of user of that API and make any unneccesary complexity transparent for the user.

I am inclined to agree that the name, ending in "Bar" could be a bit confusing, but at best renaming it would have to be to rename it to CurrentBarNumber. It is probably not critical, IMHO, but appending the "Number" certainly does make it clear that we are referencing a number, not a bar.

Yes, I agree. CurrentBarNumber is better in my opinion, better than actual CurrentBar.
But the word "Current" I still see as an complication, over simple and usable word "Last". When we agree, that NT internals should be hidden from user, then the "Last" word is best understandable. It best reflects the user-s reality - they work with the "Last" bar they have. Nothing more, nothing less. Simple and descriptive.

[koganam]

Thanx koganam, good points.

To the:CurrentBar is not necessarily the LastBar.

Yes, you are right - the bars are processed serially (not in parallel), so there can be more new bars waiting to be processed if computer is slower let's say for example. In this case, that "current" bar really does not have to be the "last" bar known in dataseries, because there are more hidden bars waiting to be processed.

I agree with that completely, but I would say, this is exact view from technical perspective how bars are processed internally.
But from perspective of developer of trading strategies - there is nothing like "hidden bars waiting to be processed in NT internals". What we have - is only the "last" and rightmost bar that is put for processing now. That's is all we can do. For us developers it is the same, as such "future waiting" bars really do not exist, because we are not and probably should not be aware of them.
We can do nothing with the future bars queued to be processed in NT internals.
That's why I do not find it useful to think about with real level of technical complexity, that is not exposed to the user and public API.

From perspective of user of public API, all we have in every point of time is only the "last" bar, everything other are just NT internals (including queued unprocessed bars).

I would prefer, that public PI should expose things from perspective of user of that API and make any unneccesary complexity transparent for the user.




Yes, I agree. CurrentBarNumber is better in my opinion, better than actual CurrentBar.
But the word "Current" I still see as an complication, over simple and usable word "Last". When we agree, that NT internals should be hidden from user, then the "Last" word is best understandable. It best reflects the user-s reality - they work with the "Last" bar they have. Nothing more, nothing less. Simple and descriptive.

An interesting semantic argument, but I guess we shall just have to leave our disagreement intact.

For most of us, I should think, the statement: "If the bar that is being processed Currently (in this serial moment of processing), is numbered zero, exit the code block immediately." makes more sense than, "If the LastBar on the chart is numbered zero, exit the code block immediately."

To me, LastBar connotes the immediate value, at any moment in time, that is the last bar on the chart (in NT7, that would be the bar numbered Bars.Count -1, or Bars.Count - 2, depending on if COBC is false or true), not the bar that is in process. The bar that is currently in process is the CurrentBar.

[NinjaTrader_Brett]

Thanks for bringing it up, CurrentBar is used so much in our documentation and underlying code that I wouldn't want to abandon it now. We are past the window to where we could make large rename changes like this in the core of the NinjaScript support. Furthermore I feel that CurrentBar is the accurate term for it as under the hood CurrentBar has nothing to do with "last bar". It is literally is the CurrentBar that is in processing by NinjaTrader. However I understand you could semantically argue that all day, but since we already have a bias toward CurrentBar we would need a strong reason to change it. Which we just don't have at the moment.

[eDanny]

On a chart with 5000 bars, using Close[CurrentBar] refers to the close of bar #0 (Close[5000]). Although that may not seem intuitive using Close[LastBarNumber] would even be less so.

[koganam]

On a chart with 5000 bars, using Close[CurrentBar] refers to the close of bar #0 (Close[5000]). Although that may not seem intuitive using Close[LastBarNumber] would even be less so.

Even better point than I made. Thanks.

[misova]

On a chart with 5000 bars, using Close[CurrentBar] refers to the close of bar #0 (Close[5000]). Although that may not seem intuitive using Close[LastBarNumber] would even be less so.

Yes, you're right.
The core of the problem is a little bit more related to accesing of bars, which can be done in 2 ways using NT API:
- using bar-index is the most commonly used, but cannot be used to mark some specific bar across multiple calls of OnBarUpdate()
- using bar-number is generally more useful everywhere, because it can be used for iteration of bars and also for marking/storin any specific bar everywhere.

I would prefer, if NT used only one way of indexing by bar-number so the concept of accessing bars would be only one and the bar-number specifies concrete bar forever. But this is different story...

[misova]

Yes, thank you all for your comments.
It is definitely interesting topic for me and it is more about fundamental concept under the hood of NT, which is probably not easy to change or refactor in beta phase of development.

I can live that and be happy - it is really not so critical.

It may have also some benefits later, that we can sell more ebooks and webinars explaining how things really work

[koganam]

Yes, you're right.
The core of the problem is a little bit more related to accesing of bars, which can be done in 2 ways using NT API:
- using bar-index is the most commonly used, but cannot be used to mark some specific bar across multiple calls of OnBarUpdate()

Huh? Of course you can. That is like saying that you cannot access a specific index in a List.

[misova]

Huh? Of course you can. That is like saying that you cannot access a specific index in a List.

I meant, that storing bar-index as a pointer to some specific bar, that will be used
later will not work, because bar-index is floating and will reference different bar
later - so we have to store bar-number, as a reference information,
if we want to access same bar in the future.

[NinjaTrader_ChelseaB]

Hello misova,

In this case, record the CurrentBar value to a variable. This is pointer that will not change.

int savedBarNumber = CurrentBar;

Then when you want to find that bar, subtract this number from the CurrentBar to get a bars ago value.

Close[CurrentBar - savedBarNumber]

This will let you easily find the same bar every time.

[Shansen]

misova,

Should it be of use, for ease of reference I use the below code in UserDefinedMethods.cs in the namespaces Ninjatrader.Indicator and Ninjatrader.Strategy. Simple, but effective.

public int GetBarsAgo(int barNumber) 
{
  return CurrentBar - barNumber;
}

Regards
Shannon