State of an indicator, time or currentbar?

[AndBro]

Hello,

Assume two indicators, A and B.

A is like: OnBarUpdate() {Value[0] = B()[0];}

B is like: OnBarUpdate()
{
if ((CurrentBar == 8) && (InterestingBar == 5))
{
Value[2] = -1; // Here I do "back to the future" !!!
Value[0] = Value[1];
InterestingBar = 0;
}
else
{
Value[0] = 1;
}
}

InterestingBar is private int at B.

At a first glance, it is easy to think that indicator A always will generate the same result as indicator B. But it doesn’t (and I understand why). See attached image.

It is no problem to find out what is wrong in my example, but if you have a whole chain of indicators, ”errors” like this might be very difficult to find.

The conclusion is that an NT object, will have a different state (values of local variables) depending on when the object is executed, but with the same value of CurrentBar. Is this the design, or is it a bug?

If not a bug!

What are the NT-recommendations if it is absolutely necessary to something like Values[2]; (this will occur if you are doing statistic analyses of bar-data, rather than a future prediction)?

Thank you, AndBro

P.S: Of course, you should never “look back” (ie Value[2]) in an indicator, because that is the same as “looking” in to the future and telling the result today.

[NinjaTrader_JessicaP]

Hello AndBro, and thank you for your question.

Briefly, every NinjaScript object has its own state and its own state progression. A sub-indicator's state is not dependent on the parent strategy's state. Any messages to be passed between the sub-indicator and parent strategy (or any other parent-child communication) should be done with asynchronous messages. A great way to make sure that your methods will work well for asynchronous communication is with the static keyword. This will prevent you from using any time dependent NinjaScript instance variables. A code example where this is accomplished is as follows :

private static int InterestingBar = 0;
public static void setInterestingBar(int value)
{
    InterestingBar = value;
}

Using methods like this will give you greater control over when information is set from the parent. If you are concerned that information may change mid-execution, for example

private void SomeMethod()
{
    // InterestingBar is 3 here
    // time consuming code is here
    // InterstingBar is 5 here
    Print("InterestingBar : " + InterestingBar); // we would like to print 5 instead of 3
    // time consuming code is here
}

Then in those instances you will want to use the volatile keyword as well as the static keyword.

I am including a quote from the documentation on the Lifecycle of NinjaScript objects, and another quote from the documentation on Historical Order Backfill Logic. Please let us know if there are any other ways we can help.

UI versus analysis object instances

First we need to understand the basic architectural concept of two NinjaScript object instances working in tandem -


a. An instance that is created to be used for displaying the object in the user interface dialogues (i.e. indicator selector on your chart)
b. And then the actual instance that would be applied to your NinjaTrader window for analysis purposes



Opening up the selector will trigger a call to State.SetDefaults for all objects of the respective namespace, i.e. Indicator, Strategies etc. The same would hold true for State.Terminated if the selector is closed down, thus to not impact any actually configured and running objects you want to make sure any use of custom resources and items you want to reset, are managed outside those states or only triggered if a property or resource needs a reset change back and the initiative action was taken by your object specifically
(more information as to what this means available behind link)

Understanding How Orders are backfilled for NinjaScript strategies

NinjaScript strategies use an algorithm to process order fills on historical data in two scenarios: when processing fills in the Strategy Analyzer, or when processing historical orders for a live running strategy. The algorithm fills historical orders using the same set of logic in both scenarios. Below is an outline of the logic used to determine the appropriate fill price for each historical order. When more than one order needs to be filled at once, the logic below will be ran for each individual order in succession.


General Outline

The steps involved in determining the appropriate fill price for an order are documented in their own sections below. The general, top-level outline of the logic can be broken into three steps:


1. Prepare to calculate fill prices
2. Take three passes to calculate the appropriate fill price for each order which needs filled
3. Fill the orders using the calculated fill price
(more detailed information behind link)

[AndBro]

Hello Jessica, thank you for helping me to understand the lifecycle of an indicator. I read your links, and studying my own indicators with tons of trace-prints.
After doing that, it looks like I was wrong from the very beginning. My concern was that an indicator could behave different the second or third it was called (time = 0, indX()[0], time = 1, indX()[0], time = 3, indX()[0],). As I understand now, NT always make sure that when an indicator executes it will always execute, as it was the first time no matter if the indicator executes many repeating times (no static variables). F(x) = State(indY()[x]) and G(x) = State(indY()[x]), gives that F(x) = G(x) ALWAYS.

The reason for my concern is that I have a very complex and long chain of indicators (no static variables) and the result is sometimes confusing! I now think that this problem is due to my own logic, and not due to the NT engine.

Thank you /Anders

[NinjaTrader_JessicaP]

I am glad you were able to diagnose the script's behavior. Please let us know if there are any other ways we can help.