Call one strategy from another

stolmax

#1

8/30/2009 7:42 PM

Is there a way to programmatically call one strategy from another? Thanks

Cone

#2

8/31/2009 2:50 AM

If there were, and there could be, it's not part of the intended design.
What's the goal here?

As Robert said, firstly we need to know the goal. From the technical standpoint, there are some possible ways to "call" a strategy.

The first is outlined in our Wiki KB article, Interacting Dynamically with Portfolio Level Equity, and includes making a call to the undocumented method "TradingSystemExecutor". Since it's unsupported, you can download the source code for Community.Components and dig deeper into Utility.cs which contains all the code. This is how Wealth-Lab itself executes a strategy internally.

The other one is more straightforward and can be used to create a primitive "multi-system" script:

Size:

Color:

As Robert said, firstly we need to know the goal. From the technical standpoint, there are some possible ways to "call" a strategy.

The first is outlined in our Wiki KB article, [LINK=http://www2.wealth-lab.com/WL5WIKI/kbInteractingWithPortfolioEquity.ashx]Interacting Dynamically with Portfolio Level Equity[/LINK], and includes making a call to the undocumented method "TradingSystemExecutor". Since it's unsupported, you can download the source code for [LINK=http://www2.wealth-lab.com/WL5WIKI/CommunityComponentsMain.ashx]Community.Components[/LINK] and dig deeper into [i]Utility.cs[/i] which contains all the code. This is how Wealth-Lab itself executes a strategy internally.

The other one is more straightforward and can be used to create a primitive "multi-system" script:

[CODE]
using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;

namespace WealthLab.Strategies
{
	public class Multisystem : WealthScript
	{
		protected override void Execute()
		{
			System1.Run(this);
			System2.Run(this);
		}
	}
	
	class System1
	{
		public static void Run(WealthScript obj)
		{
			for(int bar = 20; bar < obj.Bars.Count; bar++)
			{
				if (obj.IsLastPositionActive)
				{
					obj.SellAtStop( bar+1, obj.LastPosition, Lowest.Series( obj.Low,10 )[bar] );
				}
				else
				{
					obj.BuyAtStop( bar+1, Highest.Series( obj.High,20 )[bar], "System1" );
				}
				
				// Workaround to prevent open positions from one system to be available for the next system to close
				if( bar == obj.Bars.Count-1 )
					obj.SellAtClose( bar, Position.AllPositions, "Close All" ); 
			}
		}
	}
	
	class System2
	{
		public static void Run(WealthScript obj)
		{
			for(int bar = 20; bar < obj.Bars.Count; bar++)
			{
				if (obj.IsLastPositionActive)
				{
					obj.SellAtMarket( bar+1, obj.LastPosition );
				}
				else
				{
					obj.BuyAtLimit( bar+1, obj.Low[bar]*0.95, "System2" );
				}

// Workaround to prevent open positions from one system to be available for the next system to close
				if( bar == obj.Bars.Count-1 )
					obj.SellAtClose( bar, Position.AllPositions, "Close All" ); 
			}
		}
	}
}
[/CODE]

stolmax

#4

8/31/2009 8:36 AM

Thanks Eugene and Cone,

I need to call a strategy from a strategy in order to do profiling on various stocks. I have created a db of various stock and their relationships and now would like to automatically run a strategy against these relationships in order to determine the stocks against which an underlying strategy performs the best. BTW, this is for a pair trading strategy. Thanks

Max

Partha

#5

9/29/2019 2:32 AM

I am trying to setup a system with two strategy based on the template provided in this thread. I am getting an error with the PrintDebug method in the code below. Can you please help

the error is "the name PrintDebug does not exist in the current context"

Eugene

#6

9/29/2019 5:08 AM

If you carefully review the code from post #3 you would notice that each and every call (reference) to a WealthScript object or method in the child Strategies (Strategy1, Strategy2) is prefaced with the object name passed on to it like:

Notice the "obj."? This is how you have to refactor the call to PrintDebug and whatever else WealthScript method/object you plan to use in there.

Partha

#7

9/29/2019 5:35 AM

thanks Eugene...it works...I am still learning C# and object oriented programming...and I greatly appreciate the help from you and Cone

superticker

#8

9/29/2019 5:41 AM

This confused me too when I first started writing DLL libraries. You'll notice from the code below that only the "class Multisystem : WealthScript" inherits an instance of WealthScript, which leaves the other classes out in the cold when trying to run WealthScript member functions like PrintDebug().

Moreover, the WeathScript instance may have state (i.e. field) variables the WealthScript functions need. So the trick is to pass Multisystem's instance of WealthScript (and its state variables) into the other classes as a parameter; I typically call it "WSObj." in the class being called. Then you need to prefix any WealthScript function used by the child classes with that prefix so it can access Multisystem's WealthScript instance.

Partha

#9

9/29/2019 5:53 AM

thanks superticker...I really like the help I get on this forum from advanced users like you and others..

superticker

#10

9/29/2019 2:46 PM

I wouldn't create a Strategy1 and Strategy2 as Post# 3 does--that design is flawed--because they won't run asynchronously from each other as separate threads. Instead, develop your code as a single strategy with auxiliary classes and functions being called. Now you can have multiple trading entry (Buy) and exit (Sell) points in your trading FOR loop (I do that.), but if you do, WL won't gather separate statistics for each entry and exit point. But let's start a new topic if we want to talk about that.

If your goal from this discussion is to "monitor" combination strategies executing asynchronously, then read Wealth-Lab User Guide >> Strategy Window >> Combination Strategy. And be sure to start a new forum topic if you have questions.

Eugene

#11

10/2/2019 1:49 PM

Here's the threaded version. It's just a minor change:

Size:

Color:

[quote]I wouldn't create a Strategy1 and Strategy2 as Post# 3 does--that design is flawed--because they won't run asynchronously from each other as separate threads.[/quote]
Here's the threaded version. It's just a minor change:

[code]using System;
using System.Collections.Generic;
using System.Text;
using System.Drawing;
using WealthLab;
using WealthLab.Indicators;
using System.Threading.Tasks; // <- run the subsystems in multiple threads via Task

namespace WealthLab.Strategies
{
	public class Multisystem : WealthScript
	{
		protected override void Execute()
		{			
			Task.Run(() => System1.Run(this));
			Task.Run(() => System2.Run(this));
		}
	}
   
	class System1
	{
		public static void Run(WealthScript obj)
		{
			for(int bar = 20; bar < obj.Bars.Count; bar++)
			{
				if (obj.IsLastPositionActive)
				{
					obj.SellAtStop( bar+1, obj.LastPosition, Lowest.Series( obj.Low,10 )[bar] );
				}
				else
				{
					obj.BuyAtStop( bar+1, Highest.Series( obj.High,20 )[bar], "System1" );
				}
            
				// Workaround to prevent open positions from one system to be available for the next system to close
				if( bar == obj.Bars.Count-1 )
					obj.SellAtClose( bar, Position.AllPositions, "Close All" ); 
			}
		}
	}
   
	class System2
	{
		public static void Run(WealthScript obj)
		{
			for(int bar = 20; bar < obj.Bars.Count; bar++)
			{
				if (obj.IsLastPositionActive)
				{
					obj.SellAtMarket( bar+1, obj.LastPosition );
				}
				else
				{
					obj.BuyAtLimit( bar+1, obj.Low[bar]*0.95, "System2" );
				}

// Workaround to prevent open positions from one system to be available for the next system to close
				if( bar == obj.Bars.Count-1 )
					obj.SellAtClose( bar, Position.AllPositions, "Close All" ); 
			}
		}
	}
}[/code]

superticker

#12

10/2/2019 3:39 PM

1) Are you saying this threaded version will let the Combination Strategy window do it's job as expected? (I think this weird approach defeats the purpose of the Combination Strategy window and gives you less control.)

2) What about tracking performance separately from Strategy1 (or System1) and Strategy2 (or System2)? Can this still be realized with Performance Visualizers?

If the answer to either is "no", then this entire concept is a bad idea over running Strategy1 and Strategy2 as separate strategies at the Strategy Monitor level, which is the normal way.

And even if the answer is "yes" to both questions above, I'm not sure why you would want to run two separate strategies under the control of one execution block. What's the gain here over using the Combination Strategy window to do the same thing? (I think we're breaking the intended WL model here.)

Eugene

#13

10/2/2019 4:25 PM

Despite the design pattern from post #3 had been shown (in 2009) a couple years before Combo Strategies were even drafted (2011), there's still a couple cases it can be applied to. Please see Note in the Wiki article for Combo strategy's limitations:

WealthScript Techniques | MultiSystem, or Calling a Strategy From Another

Unlike Combo Strategies that fully support separate performance tracking for child strategies, to my knowledge it's just the Contribution pie chart that has very limited support in the form of breakdown by entry/exit signal name.

superticker

#14

10/2/2019 6:00 PM

That might be the only real justification for not using the Combination Strategy window today.

But either way (whether you employ Combination Strategy methods or a multi-strategy Execute control block), you're going to have to communicate between the two asynchronous strategies via Global variables because all other variables are private (which is a good thing).

Communicating via Global variables is okay only if one asynchronous task treats the other's variables as read-only. In other words, one task only listens to the other task's variables, but does not modify them. As a real-time engineer, I only know too well what happens when you have different tasks messing with the other's variables in shared memory. It's a debugging nightmare because none of the real-time bugs are reproducible. I wouldn't encourage this program design.

UPDATE: Well, you could pass two shared objects as parameters such that each task gets his own object by "ref" and the other does not:

This way each task owns its own shared object and the other can only read it to communicate and synchronize. Now you won't have to use Global variables and each task's own variables are "protected" from the other task's bad behavior. That's the main (only?) advantage of the multi-task Execute-control-block approach. Perhaps you can update the example in the multi-system link with this feature. Weird solution ...

Size:

Color:

[quote]Please see Note in the Wiki article for Combination Strategy window limitations: ... "If you need the Combo strategies to interact and thus influence trading decisions in another strategy."[/quote]That might be the only real justification for not using the Combination Strategy window today.

But either way (whether you employ Combination Strategy methods or a multi-strategy Execute control block), you're going to have to communicate between the two asynchronous strategies via Global variables because all other variables are private (which is a good thing).

Communicating via Global variables is okay only if one asynchronous task treats the other's variables as [u]read-only[/u]. In other words, one task [u]only listens[/u] to the other task's variables, but does not modify them. As a real-time engineer, I only know too well what happens when you have different tasks messing with the other's variables in shared memory. It's a debugging [u]nightmare[/u] because none of the real-time bugs are reproducible. I wouldn't encourage this program design.

UPDATE: Well, you could pass two shared objects as parameters such that each task gets his own object by "ref" and the other does not:
[code]      protected override void Execute()
      {         
         Task.Run(() => System1.Run(this, ref sharedObj1, sharedObj2));
         Task.Run(() => System2.Run(this, sharedObj1, ref sharedObj2));
      }[/code]
This way each task owns its own shared object and the other can only read it to communicate and synchronize. Now you won't have to use Global variables and each task's own variables are "protected" from the other task's bad behavior. That's the main (only?) advantage of the multi-task Execute-control-block approach. Perhaps you can update the example in the multi-system link with this feature. Weird solution ...