Announcement

Collapse
No announcement yet.

Partner 728x90

Collapse

Indicator that calls and Indicator

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

    Indicator that calls and Indicator

    I am trying to setup and Indicator that uses the output of another indicator and I am not having any luck.

    I am setting up an Indicator Variable (name of Indicator) such as:
    GHPInd m_TM;


    Then in the OnStateChange (and I have tried Configuration, DataLoaded and Historical) I assign the indicator to this variable:

    m_TM=GHPInd();
    And tried:
    m_TM=GHPInd(Bars);


    OnBarUpdate()
    RawPlot[0]=m_TM[0];

    I Also tried this to see if the interim assignment was wrong but got the same results:
    RawPlot[0]=GHPInd()[0];


    In the OnBarUpdate() I simply copy the primary data from m_TM into the plot (Prior to my filtering) and the data is corrupted some how. It is almost like the GHPInd is not getting the same data stream.

    I have tried this connected to NTBroker with "Tick Replay" checked for the Data Series. I also gave up thinking it was something I was doing wrong and simply went to the "Play Back" connection. In both cases I got different results. In the chart below, both RED lines should be the same function. One is the primary (Bottom panel) and the middle panel is the output of the "Indicator within an Indicator" I described above.

    They both should be equal. The primary indicator does use the "OnMarketData()" callback. The passthrough indicator does not use the OnMarketData() callback.

    I am stuck trying to pass data from one Indicator to another. I didn't try this with something like SMA, but I would hope there isn't much different.

    #2
    Without looking at code, I believe based off what you're saying, if you're calling m_TM[0] you're simply going to access the raw input data (Close series).

    If you're trying to get some calculation of that indicator you're calling, you need to access it's Value, if there are no other public plots or series.

    Code:
    protected override void OnBarUpdate()
    {
         Print(myIndicator1[0]) // Close series of the indicator's input
         Print(myIndicator1.Value[0]);  // Calculated value of indicator 
    }
    If that does not help, do you have a sample script which demonstrates that problem you are facing?
    MatthewNinjaTrader Product Management

    Comment


      #3
      Actually, sorry - in response to above, I was thinking of the GetValueAt() method when dealing with absolute Bar Index values. Your approach should work.

      At any rate, there is something that is not adding up and would appreciate a look at a sample script which demonstrates this misbehavior.
      MatthewNinjaTrader Product Management

      Comment


        #4
        Originally posted by NinjaTrader_Matthew View Post
        Without looking at code, I believe based off what you're saying, if you're calling m_TM[0] you're simply going to access the raw input data (Close series).

        If you're trying to get some calculation of that indicator you're calling, you need to access it's Value, if there are no other public plots or series.

        Code:
        protected override void OnBarUpdate()
        {
             Print(myIndicator1[0]) // Close series of the indicator's input
             Print(myIndicator1.Value[0]);  // Calculated value of indicator 
        }
        If that does not help, do you have a sample script which demonstrates that problem you are facing?
        Hi Matt,

        That worked, I don't understand why because of the public access to the variable name:
        Code:
                [Browsable(false)]    // this line prevents the data series from being displayed in the indicator properties dialog, do not remove
                [XmlIgnore()]        // this line ensures that the indicator can be saved/recovered as part of a chart template, do not remove
                public Series<double> StackedOutput
                {
                    get { return Values[0]; }
                }
        I guess I don't understand why there would be a difference if I referenced:
        Indicatorxxx.StackedOutput[0]
        vs
        Indicatorxxx.Values[0][0]

        This does seem to make a difference, it is going to be a pain to always translate the name to the index which means if the called indicator changes for some reason, the calling indicator could break because the data moved in index.

        It would be nice if both of the above returned the same value...

        Comment


          #5
          I cannot replicate the problem - I tried calling local and remote indicator's series and they all had the same values:
          Code:
          Print("this: " + this.Default[0] + "; remote: " + gradientRsi.Default[0] + "; remote2: " + gradientRsi[0] + "; remote3: " + gradientRsi.Values[0][0]);
          eg. from output window:
          Code:
          this: 65.0026751124095; remote: 65.0026751124095; remote2: 65.0026751124095; remote3: 65.0026751124095

          Comment


            #6
            Originally posted by gregid View Post
            I cannot replicate the problem - I tried calling local and remote indicator's series and they all had the same values:
            Code:
            Print("this: " + this.Default[0] + "; remote: " + gradientRsi.Default[0] + "; remote2: " + gradientRsi[0] + "; remote3: " + gradientRsi.Values[0][0]);
            eg. from output window:
            Code:
            this: 65.0026751124095; remote: 65.0026751124095; remote2: 65.0026751124095; remote3: 65.0026751124095
            Does the gradientRsi indicator use the OnMarketData() callback for its calculations? This may not be an issue if your indicator uses only the OnBarUpdate().

            Comment


              #7
              Originally posted by NJA_MC View Post
              Does the gradientRsi indicator use the OnMarketData() callback for its calculations? This may not be an issue if your indicator uses only the OnBarUpdate().
              That could be the case - mine only uses OnBarUpdate()

              Comment


                #8
                Originally posted by NinjaTrader_Matthew View Post
                Actually, sorry - in response to above, I was thinking of the GetValueAt() method when dealing with absolute Bar Index values. Your approach should work.

                At any rate, there is something that is not adding up and would appreciate a look at a sample script which demonstrates this misbehavior.
                Hi Matt,

                I am having a little trouble reproducing the exact issue but think it is related to the "calculate" setting and RANGE BARS.

                I found one other issue as well related to the data box being open, not sure it was reported yet. I can walk you through that issue as well. Also, I don't think I posted the Image to my original post #1 so I have enclosed it here as the one with the 2 RED plots.

                I have enclosed "TestSamples.zip" which will help reproduce the potential error, I will keep looking to see if I can reproduce my original problem but it might be related to what I describe here.

                Setup:
                Load the CL 06-15 into a 1 Min chart, and setup the "Tick Replay" (or you will need to use playback mode) The indicator needs the "OnMarketData() to fire".

                Add the included TEST indicators. They are a very simple CD calculation and an indicator that pulls that data and passes it to the indicator output. Both should have Calculate == OnBarClose.

                Both Orange Traces should match as one is simply passing the data from the first indicator through to its plot.

                You can set the "Calculate" setting on one of the indicators, doesn't matter, to Something Other than OnBarClose, again, both traces will match.

                Now switch the ANY RANGE setting, I used 1 and 2. Here you will see something closer to the attached image with the Orange traces. Something happens to the non "OnBarClose" indicator with Range bars selected.

                You can select any other Chart Type and the two traces will match again, I tried DAY, TICK, SECOND, Volume. All these seem to work fine. This might be the related to the issue I saw yesterday as I do use the RANGE chart style.

                For the 2nd issue and the attached Exception. Simply open the DATA BOX.

                Now switch a few times between "Calculate" OnBarClose and something else. This box should pop-up. The exception in the logs looks like this which told me it was the Data Box:

                2015-05-18 20:20:27:373 *************** unhandled exception trapped ***************
                2015-05-18 20:20:27:373 'barsAgo' needed to be between 0 and 522 but was -4388
                Parameter name: barsAgo
                2015-05-18 20:20:27:373 System.ArgumentOutOfRangeException: 'barsAgo' needed to be between 0 and 522 but was -4388
                Parameter name: barsAgo
                at NinjaTrader.NinjaScript.Series`1.IsValidDataPoint( Int32 barsAgo)
                at NinjaTrader.Gui.Chart.ChartControl.UpdateDatabox(B oolean force)
                at NinjaTrader.Gui.Chart.ChartControl.<>c__DisplayCla ss13.<OnIndicatorsHotKey>b__d()
                at NinjaTrader.Gui.Chart.ChartControl.OnIndicatorsHot Key(Object sender, KeyEventArgs e)
                at NinjaTrader.Gui.Chart.ChartCommands.IndicatorsExec uted(Object sender, ExecutedRoutedEventArgs e)
                at System.Windows.Input.CommandBinding.OnExecuted(Obj ect sender, ExecutedRoutedEventArgs e)
                at System.Windows.Input.CommandManager.ExecuteCommand Binding(Object sender, ExecutedRoutedEventArgs e, CommandBinding commandBinding)
                at System.Windows.Input.CommandManager.FindCommandBin ding(CommandBindingCollection commandBindings, Object sender, RoutedEventArgs e, ICommand command, Boolean execute)
                at System.Windows.Input.CommandManager.FindCommandBin ding(Object sender, RoutedEventArgs e, ICommand command, Boolean execute)
                at System.Windows.Input.CommandManager.OnExecuted(Obj ect sender, ExecutedRoutedEventArgs e)
                at System.Windows.RoutedEventArgs.InvokeHandler(Deleg ate handler, Object target)
                at System.Windows.EventRoute.InvokeHandlersImpl(Objec t source, RoutedEventArgs args, Boolean reRaised)
                at System.Windows.UIElement.RaiseEventImpl(Dependency Object sender, RoutedEventArgs args)
                at System.Windows.Input.RoutedCommand.ExecuteImpl(Obj ect parameter, IInputElement target, Boolean userInitiated)
                at System.Windows.Controls.MenuItem.InvokeClickAfterR ender(Object arg)
                at System.Windows.Threading.ExceptionWrapper.Internal RealCall(Delegate callback, Object args, Int32 numArgs)
                at MS.Internal.Threading.ExceptionFilterHelper.TryCat chWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
                Attached Files

                Comment


                  #9
                  Thanks for the report, I just wanted to let you know I'm still looking into this
                  MatthewNinjaTrader Product Management

                  Comment


                    #10
                    Hello,

                    I've just tested this on my end, and based on how IndicatorInIndicator is set up, it looks like this behavior is to be expected. IndicatorInIndicator is creating a new instance of TestCD within it's own class, rather than referring to the instance of TestCD that is on your chart. With Tick Replay disabled, we would expect both indicators to show the same values on historical data, but this would not be the case with Tick Replay enabled, as the historical data will be processed virtually the same as real-time data.

                    Because of the way this is set up, the "Calculate On" settings for IndicatorInIndicator will be applied to the instance of TestCD created within it, as well, and this will be independent of the settings applied to the other instance of TestCD on your chart. On my end, I'm seeing differences on any interval type (including Range, but all others as well) with different "Calculate On" settings, while seeing the same values with identical "Calculate On" settings.

                    I'm not able to reproduce the error you are seeing with the data box, though. Are there any other factors at play that I might need to address in order to replicate the issue?
                    Dave I.NinjaTrader Product Management

                    Comment


                      #11
                      David,

                      I will see if I can absorb what you are saying in regard to expected behavior. This may now work out for the coding community, but I will try to work with it to see what this may cause to strategies/indicators during backtesting, etc.

                      As for the DataBox issue. I just happen to bump into this issue again. As best I can tell, it was due to me creating a new instance of an Indicator, within my indicator in the "DataLoaded" State rather than "Configure" state. It seems like this process is very sensative to where you create your dependant indicators.

                      I will see if I can do more tests in this area, but the problem seemed to clear up after moving the creation of the indicator to the different state block.

                      Comment

                      Latest Posts

                      Collapse

                      Topics Statistics Last Post
                      Started by maybeimnotrader, Yesterday, 05:46 PM
                      1 response
                      18 views
                      0 likes
                      Last Post NinjaTrader_ChelseaB  
                      Started by Perr0Grande, Yesterday, 08:16 PM
                      1 response
                      7 views
                      0 likes
                      Last Post NinjaTrader_Jesse  
                      Started by f.saeidi, Yesterday, 08:12 AM
                      3 responses
                      25 views
                      0 likes
                      Last Post NinjaTrader_Jesse  
                      Started by algospoke, Yesterday, 06:40 PM
                      1 response
                      14 views
                      0 likes
                      Last Post NinjaTrader_Jesse  
                      Started by quantismo, Yesterday, 05:13 PM
                      1 response
                      14 views
                      0 likes
                      Last Post NinjaTrader_Gaby  
                      Working...
                      X