Is it OK to store indicator object in your custom code?

[aviat72]

Ninjatrader maintains an internal cache for every indicator defined on a particular instrument which compares the parameters used to make the indicator call. This cache code is visible in the "NinjaScript Generated Code..." part at the end of any indicator.

Is it OK to store the indicator object returned by a call to the indicator as a local class variable?

i.e.


In my code I have the following:

Initialize(){

    SMA mySMA = SMA(10);
}

OnBarUpdate(){
   if(mySMA[0] > mySMA[1]){
  .....
}
}

Currently we would write the barUpdate part as

if(SMA(10)[0] > SMA(10)[1]){
.....
}

I want to cache the indicator objects because:

1. If your indicator takes multiple parameters, writing all of them out becomes laborious and error prone, especially in more complex operations. Writing CustomIndicator(param1, param2, param3, param4)[0] is more error prone than myCI[0];
   
2. You reduce computation overhead since you by-pass the cache look up phase every time you make a call to access the indicator. i.e. every time you encounter SMA(...), the code traverses the cache linearly and then returns the correct object for you to access.

Since indicator do not recalculate values until you do F5, it seems the indicator objects too should not be transient and hence their values persistent and suitable for storage in local class variables.

Is there anything more to it?

[NinjaTrader_Ray]

Nothing more to it, what you suggest is a good approach and more efficient of course. We do that ourselves in some of our sample scripts.

[aviat72]

Thanks for confirming this.

On a related note, there is a potential issue lurking in the NT infrastructure when you want to write more complex indicators where the signature does not capture all that is happening under the hood.

For example, I may have a database of statistical information which the indicator queries for certain parameters (e.g. average historical volatility during different half hour periods of the day). The indicator may be using that information under the hood. Two different instances of the same indicator started at different times, will behave different but will get mapped to the same object, since the external input to the indicator is not captured by the signature.

I suggest a "IsNotCachable" property with a default value of false where the user explicitly prevents caching.. The user should be aware that they would need to store the indicator object as a local variable in their custom scripts, and call methods on that object instead of making new constructor calls. Other wise a new instance object will be created every-time the custom script runs.

[NinjaTrader_Bertrand]

Thanks for taking the time to voice your thoughts and input aviat72, Happy New Year!

[Pagey]

Dear Ninjas,

The cache implemented in the indicator class is indeed very elegant and probably saves a great deal of redundant re-calculation- good job!

That said, there may be cases where multiple calls to an indicator with different parameter combinations may be used- in this case the caches fill up all available memory and may halt the machine.

Is there a way to prevent the indicator from keeping a cache, so that serial calls to an indicator would not take extra memory? The user would of course be aware that any recalculation is at his expense in this case

Any help in this direction would be greatly appreciated, and a great 2012 to you!

Pagey