Corsair Consulting LLC

Long time, no update!  :)

I have settled on a platform for general Forex development, Open Forex Platform (http://www.openforexplatform.com/).  It is open source, it has extensive backtesting and charting capabilites, it currently integrates with MetaTrader 4, and can be made to integrate with just about any broker or data source.  It is also a .NET platform.  So it is not perfect :)  Given that Scala will soon be natively appearing on .NET (see here) and that IKVM allows for importing most Java libraries, the .NET-ness of it is not a major hurdle.

I have been playing around with the Java Genetic Algorithms Package v3.4.4 (http://jgap.sourceforge.net/) via C#, from within Visual Studio 2008.  Using IKVM it was actually pretty simple.

1. Download the latest JGAP source from SourceForge.net.  Get the "Full" distro
2. I used Eclipse for the next few steps, not because its Maven integration is so great, but because of the FatJar plugin. FatJar allows you to build one single jar file for a project that includes all of the external dependencies usually found in other jar files. (As the plugin author notes, sometimes doing this can be a license violation.  Use your best judgement.) Other IDEs probably have an equivalent but I don't know what they are.  So I used Eclipse :)
3. Import the JGAP project into your Eclipse workspace, via the pom.xml
4. Build a fatJar of JGAP using the right-click context menu. Verify the all of the  Mine was named JGAP_fat.jar.
5. Compile a .NET assembly using IKVM.  The command i used was ikvmc -target:library JGAP_fat.jar. The output is JGAP_fat.dll
   
6. Create a new solution in Visual Studio
7. Create a new C# project
8. Add assembly references to the C# project, for JGAP_fat.dll and all of the dlls found in the IKVM bin directory
9. Voila, that's it!

To test whether JGAP would work properly in the .NET environment, I reimplemented the JGAP tutorial (found here) in C#.

Here is the output of a few runs:

JGAPTest.exe 75
The best solution contained the following:
3 quarters.
0 dimes.
0 nickels.
0 pennies.
For a total of 75 cents in 3 coins.

JGAPTest.exe 99
The best solution contained the following:
3 quarters.
2 dimes.
0 nickels.
4 pennies.
For a total of 99 cents in 9 coins.

Here is the source code:

<Click the article header to read the rest!>

This is part 2 of the post detailing how I got to where I am in my Forex trading project.  Here is Part 1...

It was painful, tossing aside the Visual Basic 6 code.  But the performance increase was worth it.  The Visual Basic .NET LinkedList structure made huge improvements for performance versus the VB6 Collection. Of course, performance for live trading was not an issue. The back-testing framework saw huge gains.  We thought life was good.

The .NET version of the application was not a direct conversion though.  We rectified one huge architectural mistake we had made in the VB 6 version: that the business logic of the VB6 application had been aware of whether it was running backtesting or not.  There were large branches of if/else statements for handling live versus back-testing conditions.  Updates to the internal state were being handled by the code which decided when to enter or exit trades. It was very poor separation of concerns.  That anti-pattern was not a conscious decision but the result of a lack of planning.  It was a case of too much coding and not enough thinking.

That was changed in the .NET version by using a Facade pattern.  The simulation engine was cleanly separated from the business logic. Life was much better!

But things were still not as I wanted them.  The back-testing framework had become very powerful but we were limited on the trading logic side.  Adding new technical indicators for analysis was a tedious process because I had to hack them into the existing data structures storing quote data.

Also, we had no real graphing capability for the data we had captured for back-testing.  I hacked together a graphing tool using JFreeChart.  But every time we added a new TA indicator I had to code it up not just for the .NET application but the Java graphing tool.  It was very tedious work to be doing in my spare time.  I thought this project was supposed to be fun!

And here is where we stand.  Over the years many bugs in the backtesting framework were found and squashed. Aside from the fact it did not handle roll-overs well, it was pretty decent.  But it would never be more than OK because

1. It was extremely tedious to use new indicators for trading logic.  It was days worth of effort to add one because it had to be implemented twice: once for the .NET app and once for the Java charting app
2. It was inherently tied to MB Trading. Not that there is anything wrong with those guys, but flexibility in brokers is highly desirable.

Now that my coding partner has moved on, I want to revisit the ideas we looked at previously.

In (re)evaluating this project I should lay out some basic requirements for the Forex.  Here are hard and fast requirements:

1. Back-testing of strategies
   • Use of 1-minute bars the bare minimum
   • Tick data back-testing preferable
2. Unattended, automatic execution of trades
3. Large number of technical indicators can be easily plugged in
4. Should be able to communicate to me (via email or SMS) in real time as things happen, good or bad

Here are some desires, either bells and whistles or what will make this fun rather than work:

1. Implementation (at least in part) using Scala and Java
2. Graphs with technical indicators, for live data and back-testing
3. Use of GA (Genetic Algorithms) to decide when to trade
4. Should be able to receive communications from me (via email or SMS), in emergency situations.  For example, in the case of a catasrophic news event, I would like to be able to send an SMS to it indicating it should close all positions immediately and cease trading.
5. Be portable across Forex brokers
6. Use tools that are Open Source as much as possible