Data Transfer between Strategies

[Ralph]

Hi r2kTrader and Hi all traders,

In this thread I present a basic concept how to design a class (DataTransfer) maintaining basic informations transfered from multiple strategy instantiations.

[Description("Data transfer base class.")]
public class DataTransfer
{...}

An application class derived from DataTransfer (DataTransferPL) serves as an example how to maintain the profit & loss values provided by these strategies.

[Description("Data transfer application class - Profit/Loss.")]
public class DataTransferPL : DataTransfer
{...}

The example strategy (DataTransferTest) instantiates the DataTransferPL class and transfers profit & loss date to this instance and retrieves condensed informations from this instance.

[Description("Test strategy for the DataTransfer class.")]
public class DataTransferTest : Strategy
{...}

You could/should start several DataTransferTest strategies on the same chart and/or on different charts. They do all interact with each other by the instantiation of DataTransferPL. The strategies transmit a randomly generated profit & loss and retrieve the profit & loss of this trading day and the total profit & loss generated by all strategies with every first session bar . The results are printed to the output window (open this window before starting this application).

...// Retrieve the total profit/loss until now
doubleValue = dataTransferPL.TotalProfitLoss(Time[0]);
Print("# Startegy: " + strategyName + " Total PnL until " + Time[0] + ": " + doubleValue);
...

There is an debug mode implemented. If activated, status statements for nearly all methods of the transfer classes (DataTransfer, DataTransferPL) are printed to the output window. The debug mode is activated by uncommenting the "#define DEBUG" definition in the first line of both source files. Don't forget to comment both statement when the debugging is finished.

//#define DEBUG
...
public DataTransfer()
{
 memberID = memberCount++;
 memberDict.Add(memberID, new MemberData(string.Empty, DateTime.MinValue));
#if DEBUG
 if (memberInstance != null) memberInstance.Print("DataTransfer.DataTransfer memberID: " + memberID + " new member count: " + memberDict.Count);
#endif
...
}

You can find the source code strategy installation containing two files in the attachment.

Have fun
Ralph

[r2kTrader]

Ralph,

Thank you so much for your time and contribution. I'm going to carefully read your thread and looking forward to learning all I can to get the most from the development process.

Sincerely,

[r2kTrader]

Ralph,

I'm looking over your post and I can't help but thank you again. What you are doing here is so badly needed by NT that I can't say enough.

More specifically, it is very nice to get a play by play for developing your own base class and incorporating it within your strategies. I want to get out from under the world of cut and paste everytime I build a new strategy and better manage my code so that it is centralized. Write once, use many.

This is a great template and I am going to read this post with my C# books right next to me and look forward to sharing my first class with the board.


Really, thanks again. Hopefully, NT will begin to pay more attention to this area.

[Ralph]

Hi r2kTrader,

your comment is highly appreciated, thank you very much.

It may be a good idea to execute this code example with the debug mode. It helps to understand the chronology of execution. The two code files have the debug mode disabled/commented. So, don't forget to uncomment as described.

The test evaluation is worth the effort for a different reason in addition: It provides you with a detailed inside of how competing strategies are executed with the data already available on the chart, especially if you start several strategies on the same chart or if you add an additional strategy to a chart later on. I don't know, if you do such things, but I did learn something about strategy execution with Ninja and it affected also the implemetation of the concept idea.

And in the end I support your view of how to organise code in the object oriented era. And I assure you not to use something outside the area of what NT supports. So far, only Initialize(), OnBarUpdate() and Dispose() is used as an interface to NT (these are all documented features). The rest is pure C# coding independend from the NT-interface.

Regards
Ralph

[r2kTrader]

Ralph,

I will do both.

I am really excited about the skeleton you provided for building custom namespaces. I've been reading C# books, but of course NT is its own animal so your homework is a great example.

Thank you again for sharing.



Justin

Originally Posted by Ralph

Hi r2kTrader,

your comment is highly appreciated, thank you very much.

It may be a good idea to execute this code example with the debug mode. It helps to understand the chronology of execution. The two code files have the debug mode disabled/commented. So, don't forget to uncomment as described.

The test evaluation is worth the effort for a different reason in addition: It provides you with a detailed inside of how competing strategies are executed with the data already available on the chart, especially if you start several strategies on the same chart or if you add an additional strategy to a chart later on. I don't know, if you do such things, but I did learn something about strategy execution with Ninja and it affected also the implemetation of the concept idea.

And in the end I support your view of how to organise code in the object oriented era. And I assure you not to use something outside the area of what NT supports. So far, only Initialize(), OnBarUpdate() and Dispose() is used as an interface to NT (these are all documented features). The rest is pure C# coding independend from the NT-interface.

Regards
Ralph

[Ralph]

Until now the DataTransfer base class handles construction, destruction and registration of instantiations only. I implemented a little more fuctionality: a memberlist. The memberlist stores a collection of DataTransfer instances based on pattern matching for the name strings. The instance holding the search pattern has access to the members of the list. The search pattern is a regular expression. For example "Test[A-Z]1" matches all name strings starting with "Test", followed by a capital letter A-Z, followed by the number 1.

The methods of the DataTransferPL example implementation are now operating with the memberlist (instead with all DataTransfer instances).

On the attached screenshot you see a total of 5 instantiated strategies distributed over 3 charts. Two strategies (named TestB1 and TestC1) contain a search pattern and they create their memberlists accordingly.
The memberlist activities are reported in the Ninja log tab:

• TestB1 strategy instance creates a memberlist based on search pattern "Test[A-Z]1": TestB1, TestA1
• TestC1 strategy instance creates a memberlist based on search pattern "Test[A-Z]1": TestC1, TestA1, TestB1
• TestB1 extends its memberlist with TestC1 because it is an additional match.

A strategy instance is always the first member of its own memberlist, no matter if it matches its own search pattern.

Regards
Ralph

[r2kTrader]

Ralph,

I'm re-reading this thread and catching up.

Your thread is fantastic!


Thank you again,

[astrolobe]

Hi Ralph,
Thanks very much for this code. The functionality is just what I need.
Please excuse the silly question, but should these C# files be compiled into a dll?

thanks
Grant

[Ralph]

Many thanks for the feedback, Grant.
I did compile it just the "standard way".
Is there a certain reason to put it into a dll?

Regards
Ralph

[astrolobe]

Originally Posted by Ralph

Many thanks for the feedback, Grant.
I did compile it just the "standard way".
Is there a certain reason to put it into a dll?

Regards
Ralph

I have no specific reason to put it in a dll, this is just my lack of depth in C# coming through. I thought any custom code that was not an indicator or strategy needed to be in a dll. So you learn something every day

I am learning a lot just from going through your code with a C# manual, and trying to understand it.

thanks again.

[Ralph]

Originally Posted by astrolobe

...I thought any custom code that was not an indicator or strategy needed to be in a dll...

Hello Grant,

now I understand. As you have seen already I use an own namespace. That does not matter for the compiler. It structures code and implements access permissions by the "using"-functionallity. The NT software does not know anything about this code, unless you use it in an indicator or strategy or both. You even could connect a strategy with an indicator by this transfer concept, it is no difference. But I need to decide for obvious reason where to locate the code and there are only 2 choices, indicator or strategy.

I use this kind of namespacing for library development for my NT applications.

If you extend your C# skills by reading the code also pay attention to how the code is structured. The base class contains the transfer functionality and the derived class implements an application. That is an OOP-concept. And that is where I spent the most time (for thinking) because a proper interface is valuable in terms of application and re-usability. If you like programming, then it is worth to spend some efforts too in this field (OOP).

Regards
Ralph

[astrolobe]

Thanks Ralph, you cleared up up my confusion about where to place the code. I find focusing on the C# features I need, i.e., your code, is a much easier way to learn C#, then trying to read through Andrew Troelsen's C# manual (1300 + pages !!)
After all, I need the time for trading. However, having really useful code base does save a lot of time that I would otherwise do manually.

cheers
Grant

[Ralph]

Agree Grant, trading has first priority. With this in mind I would follow the same path you descibed, finding a proper code example and expanding it when required.

Regards
Ralph

[Baruch]

Hi Ralph,
I'm trying to implement your datatransfer example, but it doesn't work in NT7.
When I add 2 strategies on 2 instruments, thats how my log looks like

17/01/11 6:08 AM Default DataTransfer instance: Test2 Memberlist created: Test2
17/01/11 6:08 AM Default DataTransfer instance: Test1 Memberlist created: Test1

As you see each member is for itself.
How do I make them all be in the same Memberlist?

Regards,
Baruch

[Ralph]

Hello Baruch,

Each strategy requesting access to the (or to a) member list has to define a member list name search pattern in the property grid field "Member search pattern". The search pattern must be a regular expression.

You defined Test1 and Test2 as the names for your 2 strategies. You could define a regular expression like Test[1-9] or Test[1-9]+ for larger numbers. And you need to define a regular expression for each strategy which should get access to the member list.

Regards
Ralph