Announcement

Collapse

Looking for a User App or Add-On built by the NinjaTrader community?

Visit NinjaTrader EcoSystem and our free User App Share!

Have a question for the NinjaScript developer community? Open a new thread in our NinjaScript File Sharing Discussion Forum!
See more
See less

Partner 728x90

Collapse

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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:

    Code:
    Initialize(){
    
        SMA mySMA = SMA(10);
    }
    
    OnBarUpdate(){
       if(mySMA[0] > mySMA[1]){
      .....
    }
    }
    Currently we would write the barUpdate part as

    Code:
    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?

    #2
    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.
    RayNinjaTrader Customer Service

    Comment


      #3
      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.

      Comment


        #4
        Thanks for taking the time to voice your thoughts and input aviat72, Happy New Year!
        BertrandNinjaTrader Customer Service

        Comment


          #5
          Calling indicator without using cache

          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

          Comment

          Latest Posts

          Collapse

          Topics Statistics Last Post
          Started by PaulMohn, Today, 05:00 AM
          0 responses
          8 views
          0 likes
          Last Post PaulMohn  
          Started by ZenCortexAuCost, Today, 04:24 AM
          0 responses
          6 views
          0 likes
          Last Post ZenCortexAuCost  
          Started by ZenCortexAuCost, Today, 04:22 AM
          0 responses
          3 views
          0 likes
          Last Post ZenCortexAuCost  
          Started by SantoshXX, Today, 03:09 AM
          0 responses
          16 views
          0 likes
          Last Post SantoshXX  
          Started by DanielTynera, Today, 01:14 AM
          0 responses
          5 views
          0 likes
          Last Post DanielTynera  
          Working...
          X