Using a Series in a common class

[JeffCO7]

Hi, I could use some guidance on two issues:

1. I would like to define a Series for use in a class. My code has trouble with the (this) statement.
2. I would like to use CrossAbove(). However, I think I need a using statement. I just can figure out which one for CrossAbove.

Note: This is sample code to help resolve the issue.

Any thoughts?

JeffCO

public class marketEvent
{[INDENT]Series<double> fastSMA = new Series<double>(this);
Series<double> slowSMA = new Series<double>(this);
int eventType;

public marketEvent ( int initval )
{[/INDENT][INDENT=2]eventType = initval;[/INDENT][INDENT]}

public int checkEvent ( int iFast, int iSlow, int i_CurrentBar, ISeries<double> price )
{[/INDENT][INDENT=2]slowSMS[0] = SMS(iSlow);
fastSMS[0] = SMS(iFast);
if ( CrossAbove( slowSMS, fastSMS, 1 ) )
{[/INDENT][INDENT=3]eventType = 1;[/INDENT][INDENT=2]}
else if ( CrossBelow( slowSMS, fastSMS, 1 ) )
{[/INDENT][INDENT=3]eventType = -1;[/INDENT][INDENT=2]}
else
{[/INDENT][INDENT=3]eventType = 0;[/INDENT][INDENT=2]}[/INDENT][INDENT]}[/INDENT]
 }

[NinjaTrader_ChrisL]

Hi Jeff, thanks for posting.

The best way to get these methods is to make a partial Indicator class then pass in the IndicatorBase from whatever indicator is calling the code e.g.

In a .cs file in the Addons folder:

namespace NinjaTrader.NinjaScript.Indicators
{
public partial class Indicator
{
int eventType;
public void PrintPriceData(IndicatorBase ib)
{
Print("Here is some price data: " + ib.Close[0]);
}

public int CalculateSignal(int iFast, int iSlow, IndicatorBase ib)
{
if ( CrossAbove( SMA(ib.Input, iSlow), SMA(ib.Input, iFast), 1 ) )
{
eventType = 1;
}
else if ( CrossBelow( SMA(ib.Input, iSlow), SMA(ib.Input, iFast), 1 ) )
{
eventType = -1;
}
else
{
eventType = 0;
}

return eventType;
}
}
}

In an indicator:

Print(CalculateSignal(10, 20, this));

Using "this" in an indicator that inherits from the indicator class refers to the IndicatorBase object.

Kind regards,
-ChrisL

[JeffCO7]

Thanks Chris,

Is there a way to do this using my own defined class and without using "partial class indicator"? I see the you provided an alternate method to code my example. But the SMA Xover was just an example.

My goal is to encapsulate all the data related to my events in its own class object. Sometimes that data needs to include a Series. (sorry if my terminology is off).

[NinjaTrader_Jim]

Hello JeffCO7,

I have an example indicator that recreates CrossAbove, and that helper method uses ISeries<double>'s.

I have attached it as it may be helpful and related to your goal. This could be created as public method in a helper class if that is something you are trying to build.

[hedgeplay]

Thanks Chris,

Is there a way to do this using my own defined class and without using "partial class indicator"? I see the you provided an alternate method to code my example. But the SMA Xover was just an example.

My goal is to encapsulate all the data related to my events in its own class object.

Hi Jeff,

I like the option Jim just offered up. I will probably use that somewhere myself.

Not exactly sure what your are trying to do but this might help.

Below is (Very "Unsupported") example code from an experiment to share data across indicators.

All lines below showed promise.

• Bias to "Concurrent" collection methods and double-layer locking, and other thread safety approaches as needed.
• The trickiest bit .. For some shared objects I wanted to ensure only that only one instance of one single indicator or strategy class was allowed to author/create and edit content. A solution?
  • A large thread-safe class per shared object works well but then adding all those classes introduces loads of additional app bloat / unwanted app complexity.
  • Did not run a solution in production but saw some potential promise in releasing time limited editor permissions to an instance by capturing and restricting access to " this.id " of the approved instance.
  • After X time with no heartbeat or content updates another instance of the indicator auto-took editorial ownership of the shared object.
  • I anyone has a better solution I am all ears.

Update ... also:

My ( public class marketEvent ) code has trouble with the (this) statement."

Yep. I would expect so.

You would lose some direct sync linkage (you may or may not need) to the indicator object but your likley to see more success in "public class marketEvent()" by replacing the "Series<>" statements in with your own Circular Arrays or any of a variety of other data collection object approaches.

If you must maintain direct tight sync with the chartbars or indicators data then Jim's method, a partial class or a child class (tricky) would be my first picks.


HedgePlay

public static class AiCommonData
{

private static bool bGlobalSwitchDebugOutputIsOn = false;
public static bool bGlobalSwitchDebugOutputIsOnGetterSetter
{
get { return AiMNQ.bGlobalSwitchDebugOutputIsOn; }
set { AiMNQ.bGlobalSwitchDebugOutputIsOn = value; }
}

public static long[] DeltaCumulativeBySessionArray = new long[1050];

public static double[] Close = new double[1050];
public static bool bArrayCloseInitialized = false;

public static Dictionary<long, double> TimeLast = new Dictionary<long, double>();
public static bool bTickMgmtDictInstanceAssigned = false;

public static ConcurrentDictionary<long, double> TimeLastConc = new ConcurrentDictionary<long, double>();
public static bool bTickMgmtConcDictInstanceAssigned = false;
public static ConcurrentDictionary<long, long> DeltaSumByBarConcDict = new ConcurrentDictionary<long, long>();
public static ConcurrentDictionary<long, long> DeltaCumulativeBySessionConcDict = new ConcurrentDictionary<long, long>();
public static bool bMgmtDeltaConcDictInstanceAssigned = false;

}

[JeffCO7]

Thanks Jim,

I appreciate the time you put into creating the sample. I can see re-reading my original post that my initial query was misleading as to my overall objective. Let me explain better.

I have written a number of indicators that have a lot of complexity and I would like to reuse some of these algorithms in other indicators. The SMA CrossOver was not the goal, but rather asimpistic example that would use series rather than some other structure defined in the common class. Sure there are workarounds for SMA. But not for the 100+ lines of code I might use to calculate a value that I want to store in a Series.

Common methods as you provided are perfect for the instances where I don't need to maintain state/history. In the cases where I do need to maintain state/history I have found two options:

1. maintain state in my parent indicator and pass the state parameters as reference into my common methods. This includes passing series.
2. create a common class with its own variables that maintains state. I like this option because I can have multiple instances of my class object constructed with different parameters. Say a "fast" instance and a "slow" instance. my class has 20 "state" variables, I don't need to create 40 different variables in my parent indicator. I just instantiate fast_obj and slow_obj and access results as fast_obj.param1, fast_obj.param2, slow_obj.param1, etc. Normal stuff.
   1. It sounds like a class that is not an indicator cannot use Series or some of the methods like CrossAbove
   2. I may have a misunderstanding related to calling indicators. I have worked before with other trading platforms that have a high overhead calling an indicator in an indicator.

Therefore, before I move forward, I will run some performance tests to see if I can accomplish my objective by creating an indicator with the resulting overhead instead of a common class. I will comment back here on my results and see if I need to get more creative or if NinjaTrader had the solution in front of me all along.

[JeffCO7]

hedgeplay,

Thanks for your great example. I have mapped out the obstacles to advancing my indicator development. A common static class with results shared between indicators was my last identified obstacle. I would like to pursue your idea. I would like to get back to it once I work this to completion.

[JeffCO7]

I evaluated putting my code in an indicator and calling it from another. That allows me to use multiple Series in the indicator if needed. However, the performance hit is high compared to other options. So I will use a common method or class when possible. But I can fall back on an indicator if needed. This evaluation is posted in this thread: