Corsair Consulting LLC

Why?  Why not!

Source of hanoi.scala

object Hanoi {
  def main (args: Array[String]) : Unit = {
    var plates: Int = 4
    
    for { j <- args } plates = try { Integer.parseInt(j) } catch { case _ => 1 }
    val soln = hanoi(plates, "A", "C", "B")
    for { i <- soln }  Console.println(i)
  }

  def hanoi(n: Int, peg1: String, peg3: String, peg2: String) : List[String] = {
    n match {
      case 1 => List( "Move the plate from " + peg1 + " to " + peg3)
      case _ => hanoi(n - 1, peg1, peg2, peg3) :::
        List( "Move the plate from "+ peg1 + " to "+ peg3) :::
        hanoi(n - 1, peg2, peg3, peg1)
    }
  }
}


Compile and invoke as "scala Hanoi" or "scala Hanoi x" where x is the number of plates to solve.

More Googling has uncovered 2 new ways to invoke Java/Scala code with MetaTrader. Both are commercial products but licenses are reasonably priced.

The first takes an approach similiar to the one demonstrated in this blog posting.  The name of the product is JavaDllBuilder.  It compiles Java code into DLLs but uses a JNI translating layer to make the code available. 

The second is more interesting.  It is called DDE for Java, a DDE client for java (naturally!)  Using the approach of a Java program accessing MetaTrader through DDE I think I can take advantage all of the heavy lifting done by MetaTrader (indicator calculation, actual communication with the broker) and do all of the fun work in Scala!

Edit:  crap -- DDE is being dropped from MetaTrader 5.  Scratch that option!

My Google-fu is strong... 

I believe I have found a way to invoke Java and Scala code from MetaTrader 4. It is not pretty but it should work.  I have not actually tested this -- this is just my thinking out loud after some searching.

1. The starting point is a compiled JAR file... either Scala or java code will do.
2. IKVM (http://www.ikvm.net).  I think this project is a product of the Mono people.  It is an implementation of the JVM designed to run under Mono/.NET.  The bytecode from the JAR file is compiled to some format that runs on the IKVM JVM runtime. This glob of bits (a dll) is then made available as a .NET assembly.
3. This little article on CodeGuru.com explains how to make a .NET assembly available as a plain old importable DLL.  It is written from the context of importing .NET code into MetaTrader.

The third step of that process would be unnecessary using NinjaTrader since it natively supports .NET stuff.

I guess the big thing is what level of JDK is supported by the IKVM JVM.  The webpage claims JSE 6 compatibility with the exception of AWT/Swing and Security classes.  Neither of those will be an issue for this project.

Edit 17 Oct 09 : Here is my followup implementing this mechanism.  Success!

Here are some of the platforms available for automated Forex trading.

MetaTrader 4: (http://www.metaquotes.net/metatrader/)

MetaTrader has a scripting language for automation, MQL4.  It allows loading foreign code via Windows dlls.  There is a lot of tool-chain distance between Scala/Java bytecode and a Windows DLL but my Google-fu seems to have found a path.  Look here for a subsequent post describing it.

MT4 has a big advantage in that many Forex brokers use it for their trading platform.

NinjaTrader: (http://www.ninjatrader.com/)

NinjaTrader automates via a .NET-derived language (C#).  Its  automation language seems capable of importing outside .NET assemblies.  The tool chain for MetaTrader involves making the JVM bytecode available as a .NET assembly.  That means that this route would work with the tool chain I found for MT4 but with one less step.

NinjaTrader works with less than a dozen brokers but the ones it works with tend to be very reputable.

Tradestation: (http://www.tradestation.com/)

This gets good reviews but is limited to the TradeStation brokerage...

QuickFix protocol (http://www.quickfixj.org/)

FIX protocol is a standard for all kinds of financial maneuvering.  There is a Java implementation.  Basically, my dream setup for this project is

1. QuickFix/J with a Scala Wrapper
2. Compose a Domain Specific Language (DSL) in Scala
3. ???
4. Profit

FIX protocol is supported by a few brokers but they are the majors: Oanda, Dukascopy, Interactive Brokers, etc.  The problem is that because you are dealing with the major players, it requires a not-insignificant outlay of money (in account minimums and monthly fees) during the development process.

The cost probably makes this route a no-go, for now.  But just for now...

Welcome to this blog. Here I plan on documenting my ongoing efforts of programmatic trading of the Foreign Exchange (FOREX) markets.

The focus of this blog will not be Forex per se -- there are plenty of resources covering technical and fundamental analysis. Instead I'll focus on the development of a trading platform using some of my favorite technologies: Scala and Java.

As of this writing I've (along with a fellow co-worker who served as both an idea man and coder) been playing with programmatic Forex trading off and on for about 3 years.  At that time the tools available (for trading and for analysis) were much less numerous than they are today.  My partner has moved on to greener pastures and I have taken several months away from the project.

Our initial development was done using the Visual Basic 6 API provided by MBTrading.com. The goal was to build an automated trading platform that was capable of full strategy back-testing.  As with any large software, our understanding of the problem domain grew as we coded.  

It became apparent after about a year of weekend hacking that limitations in VB6 made it not up to the task of real back-testing using tick data we had captured from MB Trading's feed -- the clunky/memory-leaky built-in Collection data structure made simulations run at only slightly faster than real-time.  Given a large enough data set, simulations slowed down to slower than real time. MBTading's API was available through .NET so we made the decision to migrate our code to .NET and Visual Studio 2005.

...(Part 2)