How to best structure an Indicator

[Shansen]

NT Forum,

Please help. My goal is to structure an indicator such that its operation historically will look identical under Calculate.OnBarUpdate and Calculate.OnEachTick (OR Calculate.OnPriceChange).

The indicator would have an internal List which is constructed by incrementally adding values from the last completed bar of a PriceSeries (e.g. Close[0]). Critically, each completed bar is added to the List once and once only (i.e. no missed bar and no duplicates).

The last completed bar under Calculate.OnBarClose is Bar[0]. The last completed bar under Calculate.OnEachTick is Bar[1] (i.e. Bar[0] is developing).

Critically, in the transition from Historical to Realtime, the List must have no missed bar and no duplicates.

Please find attached an ExampleIndicator which successfully implements the above. The Indicator can be tested on a chart with an existing SMA[8], added under Calculate.OnBarClose and under Calculate.OnEachTick. It will look identical historically and in realtime.

While this ExampleIndicator works, its logic is far from straightforward.

Is there a more simple approach to implement the above? A reference sample perhaps? Most likely working with the different States (i.e. .Historical, .Transition, and .Realtime)

As always, thanks
Shannon

[NinjaTrader_Jesse]

Hello,

Thank you for the post.

I reviewed the code but I do not really see anything particular that sticks out as incorrect or could be reduced. Also there would not really be a sample of exactly the logic you are trying as this is specific to what you are trying to accomplish. There are general samples of specific topics but generally no samples for logic as that would be specific to what you want.

It appears you are creating your own series and then using a list to Average the values in that list. If this is what you are attempting to do and it works, I see no issue with using C# logic to accomplish a task.

If you are instead trying to use the actual SMA indicator, you have not utilized the built in indicator but have instead implemented your own logic to average a custom list of values. The only difference would be that the SMA utilizes a Series as its input, the List has a Average extension and would only average what you put into that list. The equations may also be different on how the SMA averages VS how a List averages, the SMA uses a specific calculation where Average() uses a totally different calculation which is provided through C#.

Other than that, the only item I see is that the code uses a few methods, if there will be no other logic calling the methods the logic could be moved inline, but that is really just an aesthetic. If the code works for the purpose it is intended for, I couldn't really advise changing anything as it is already fairly minimal code.

I look forward to being of further assistance.

[Shansen]

Jesse,

Thank you for your quick response.

You are correct, the ExampleIndicator is just an example indicator. It is not intended for production. It is intended to work through and show the (complex) logic required to generate an indicator which looks identical under .OnBarClose and .OnEachTick, while correctly maintaining an internal List as part of its calculations. Critically, with no missed bar and no duplicates in the List.

The rough SMA CrossOver logic is inconsequential.

Is there any example indicators which highlight the how States (i.e..Historical, .Transition, and .Realtime) could / should be used to structure such an Indicator?

Again, thanks
Shannon

[NinjaTrader_Jesse]

Hello,

The way the states are used would completely be up to what your specific logic needs. There are only suggestions for specific NinjaScript methods or properties where the state used specifically matters. One example would be AddDataSeries, the help guide shows this used in State.Configure.

Your custom logic would go in the state that works for the use. If you need something before historical data is processed, you would need to use a state before historical to accomplish that, it would really depend on specifically what you are trying to do.

What you have now would work so long as the end result is what you expect mathematically and there are no errors being generated from the platform.

Regarding a sample, there are not really any specific samples for the states because it really depends on what specific logic you are trying to use in each state. If you are unsure when each state occurs to determine where logic should go, you could try to Print the State object see where you are. From OnStateChange you could print: Print(State); and see what state is currently executing. This is specifically helpful if you are having an error, one example would be creating an instance of an object. If you have a null error, you may need to create the object in an earlier state.


I look forward to being of further assistance.

[NinjaTrader_Jesse]

Hello,

The way the states are used would completely be up to what your specific logic needs. There are only suggestions for specific NinjaScript methods or properties where the state used specifically matters. One example would be AddDataSeries, the help guide shows this used in State.Configure.

Your custom logic would go in the state that works for the use. If you need something before historical data is processed, you would need to use a state before historical to accomplish that, it would really depend on specifically what you are trying to do.

What you have now would work so long as the end result is what you expect mathematically and there are no errors being generated from the platform.

Regarding a sample, there are not really any specific samples for the states because it really depends on what specific logic you are trying to use in each state. If you are unsure when each state occurs to determine where logic should go, you could try to Print the State object see where you are. From OnStateChange you could print: Print(State); and see what state is currently executing. This is specifically helpful if you are having an error, one example would be creating an instance of an object. If you have a null error, you may need to create the object in an earlier state.


I look forward to being of further assistance.

[Shansen]

Jesse,

Thank you for your clear response.

I am still attempting to discern the best approach on this issue of :

• structuring an indicator to perform identically under .OnBarClose and .OnEachTick (or .OnPriceChange), and
• reference (i.e. calculate upon) each bar once and once only.

The attached ExampeIndicator2, shows a difference approach implemented OnBarUpdate where lastCompleteBar is calculated as:

State==State.Realtime && Calculate!=Calculate.OnBarClose ? 1 : 0

This results in :

• .OnBarClose and .OnEachTick are identical under State.Historical.
• .OnBarClose and .OnEachTick are effectively identical under State.Realtime. However, a shortcoming exists on .OnEachTick where it fails on the requirement to reference each bar once and only once. The first bar in State.Realtime is referenced twice (attached).

Any ideas on how change the code to address this?

Again, thank you
Shannon