Flirting With Models

These might be of interest to some folks reading this blog…

Another great and free Haskell resource can be found here.

A great little Haskell tutorial for those of you who liked why’s (poignant) guide to Ruby is Learn You A Haskell. Perhaps not as zany, but also easily digestible (especially if you have previous functional programming experience).

When playing around with Artificial Immune Systems for classifiers, I stumbled across a more interesting measure of distance than the typical Euclidean measure called the Mahalanobis Distance, which incorporates the correlation of data set.

I always bounce through a fairly regular pattern when it comes to programming.  It goes a little something like: prototype an idea with Ruby code.  Find out it is slow.  Get frustrated.  Start writing code in C++.  Take a lot longer, but be impressed by how the strict type system tends to force me to write better programs.  Get frustrated with code verbosity.  Start looking for something else to program in that mixes the expressiveness of Ruby with the speed of C++ (one day I will realize that these two are probably mutually exclusive).  Decide that a more functional language will suit my needs.  OCaml?  Erlang?  Maybe something on the JVM!  Scala?  Clojure?  Get frustrated with build system (I don’t care what you say, Maven is just stupid) or lack of libraries.  Go back with my tail between my legs to Ruby.  Start looking at all the Ruby options: MRI, MacRuby, JRuby …

But wait!  How is it that I have somehow always overlooked Rubinius?  JIT compilation on LLVM?  Future multi-VM implementation (hello sandbox!)?  Holy cow!  That is AWESOME.  Rubinius is definitely my VM of choice from now on.

P.S. Totally unrelated, but check out Ruby Processing — it is pretty damn cool.

I started actively publishing some random code on github. If you want to check out my repos, click here.

If you want to inherit from a class that does not have a virtual destructor, you will be in trouble if you inherit from it publicly, because deleting through a base-class pointer will lead to nasty behavior. But having a private or protected inheritance means that you won’t be able to delete through a base class — because you won’t be ABLE to obtain a pointer to the base class.

So, no virtual destructor doesn’t mean you can’t inherit — it just means that it should be private or protected inheritance.

Of course, composition is probably a better choice, but whatever.

Optimized Firefox is fast like woah. Still got a PPC? No worries. Intel/PPC builds available nightly here.

Back testing is fairly common when analyzing the profitability of a strategy, but there are many other things to be considered besides returns.  Much of this list came from perusing Nuclear Phynance (particularly, FDAXHunter’s input).

• Length of the Period Tested: Over what time-frame did you run the test? How long was that time-frame?  What market conditions persisted over it?  The goal should be to run the strategy on as diverse a time-frame as possible, to help you discover what market factors play a critical role in the success or failure of your method.
• Out of Sample Tests & Locations: Much like above, you want to have a fairly significant and diverse set of out of sample data to test on.
• Average Trade / Win / Loss: What does the average trade of the system look like?  Are you normally profitable, or do you lost money and it was a couple fat-tail trades that gave you profitability?
• Volatility & Skewness of P&L Stream: Is your profitability stable?  Do you have a fat loss tail?  How skewed positive are you?
• Maximum Consecutive Losers / Winners: This is very important for when the system goes live.  Is five bad trades in a row a reason to pull the system?  Ten?  What is normal for the system?  When should we start getting concerned?
• Maximum Draw Down & Time: If we implemented the system, what sort of draw-downs would we have to stomach, and over how long would we have to stomach them?  I don’t care much about a 1300% return over 5 years if for 4 of them, I faced an 80% draw-down.  You would probably pull the plug long before the fifth year came around.
• Average Draw Down & Time: What does the average draw down look like?  Is it stable?
• Percent of Winners Removed Until Neutral: What percentage of our best trades do we have to remove before the system breaks?  Is it only a few?  Is our success based on a few large winners, or do we have a stable set of success?
• Histogram of P&L: What does the P&L look like, historically?  This is a visualization of the skew and volatility from above.
• Shape of Equity Curve: Are we talking about a long, smooth curve?  A curve with lots of jumps?  How much interim volatility between new highs?
• Optimal Parameter Location: Are the parameters we used in a stable location, or are they at a pin-point?  If they are at a pin-point, the success of the model is most likely the result of data-mining, instead of a true edge.  Instead, we would like to see that our parameters are in a plateau — the model remains stable for moderate changes in our parameter values.
• Performance in Other Markets: How does the model perform on securities it wasn’t designed to trade for?  Does it succeed in similar securities?  Does it fail in securities which the edge shouldn’t exist on?

All of these things should be considered along-side a simple profitability analysis, or else you will end up with a ’successful back-test of three years, blow up in three days’ scenario.

Inspired by Roger Alsing, a poster at Gamedev.net has created two very cool projects. The first is a near copy of Roger’s work, and can be found here. The second is more recent, and uses the idea of Boids to paint pictures. Check it out here. Very cool stuff.