photo by Simon Rogerson

Some time back, I’d written about NVidia’s CUDA noting that it looked ideal for many asset-pricing and monte-carlo type problems in finance.  At the time, I was hopeful that it would be quickly integrated into existing open source efforts like QuantLib, but adoption has proved slower than I’d hoped, most likely because implementing non-trivial problems on CUDA is, well, even less trivial than doing them without..

LMM on CUDA

Happily, I’ve just seen a promising first step in this direction as Über-quant and C++ artisan Mark Joshi recently announced an open-source project, Kooderive which looks to implement the LIBOR Market Model (LMM)  on top of CUDA.  His announcement on the QuantLib mailing lists reads:

Dear All,

various people have shown interest in the use of CUDA with QuantLib. I
have now made some progress on a CUDA implementation of the LIBOR
market model.

In particular, I now have a path generator for the LMM working which
does 16384 paths for 40 rates, 40 steps, 5 factor model, displaced
diffusion predictor-corrector that takes 0.1 seconds on my Quadro 4600.

The state of the project is code fragments that can be called from
other code. Those who are interested can get the code via
the subversion repository on kooderive.sourceforge.net .  The only
project file is currently for VC9 x64. It also uses thrust and the
CUDA SDK.

The next stage will be writing routines, that use QuantLib for the CPU
stuff and kooderive for the GPU stuff,  to actually price things.

A gentle reminder that I will be giving a course on the LMM and
QuantLib in June in London, and I will include a session on kooderive
if there
is sufficient interest.

I am happy to take code contributions for kooderive. However, I am not
looking for a redesign of the library or contributions which introduce
dependence on other libraries. I am interested in contributions of
separate routines and of optimizations of existing routines that do
not change interfaces.

regards

Mark
–
Pricing exotic interest rate derivatives – The LIBOR Market Model in
QuantLib June 2010, London,
http://www.moneyscience.com/training/index.html

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

During some recent travels, I read William Poundstone’s ramblingly entertaining Fortune’s Formula.  It had been sitting on my shelf after I’d originally gotten it, perused it and offhandedly discarded it as yet another of these science-is-fun-and-full-of-wacky-characters books for the butch humanities student.  My initial impression was a bit harsh as the book proved entertaining and covered a lot of ground including significant coverage of Ed Thorp and his stat arb alchemy (see here for his own papers on the topic).

One of the more compelling segments of the book relates Claude Shannon’s demon which is a nice thought-experiment / trading-strategy which illustrates the tractability of the problem of trading on a random walk market with fixed properties.  I wrote the above applet to explore the impacts of applying friction and otherwise modifying the behaviors of the market and the demon.

The original demon posited a world with no friction in which the market contains one instrument which doubled or halved in value each day.  Shannon’s demon looks to take advantage of this volatility by maintaining a portfolio which was rebalanced each day to ensure a 50/50 split between cash and the market.  The applet implements a very simple monte-carlo test-bed for Shannon’s Demon.  You can configure the demon and the marketplace along a variety of parameters, and then run many instances of the demon, each on its own self-contained random-walk market.

Although Shannon’s demon is a highly “stylized” case in the sense that it operates on a very synthetic, unrealistic and favorable formulation of a random-walk marketplace, it has spawned a great deal of interest and serious research.

Most of all, it’s a revealing illustration of the kind of reasoning one must embrace in order to address stat arb strategy development.  Enjoy.

—
Updated: March 4th – made price axis logarithmic to better reveal mc paths.

For those who spend their workdays in the markets and their weekends pondering derivatives pricing, latency, oceans of market data, portfolio optimization, and how to make every last damn thing faster, a preference for nVidia cards could prove to yield an unexpected benefit.

nVidia has recently unveiled a product line dubbed “TESLA” which leverages their absurdly fast GPUs to provide a supercomputer-like High Performance Computing (HPC) platform at a previously unimaginable price point.  TESLA computers are regular machines that have a set of slightly modified GPUs in them; modified such that they have no video out, but instead become additive processing clusters which the machine can use for compute intensive tasks.  For about $10K you can buy a 1U machine with some 4 teraflops of capacity.  By way of comparison, this is over 20 times faster than the funky Helmer project I’d been drooling over a few months ago in a production-worthy package ready for the server room today.

So, TESLA refers to the machines built with these specialized GPUs.  Making all this power usable is what CUDA is about…

CUDA is nVidia’s model for parallel programming that provides a C-based software environment for the development of applications that take can advantage of nVidia’s GPU architecture.  These advantages center around parallelism, torrential memory bandwidth and obscene floating point performance.   The below graphs illustrate these advantages against high-end Intel hardware.

Although I haven’t yet taken the plunge and purchased one of the trick new TESLA machines, I have been able to dip my toe into the waters as CUDA will work with most newer nVidia cards.  All you need to do is download the CUDA environment and SDK and you can very quickly get up and running.  They have an expansive and well-documented set of examples including many of interest to algorithmic traders – particularly surrounding derivatives pricing and monte-carlo methods.  I haven’t tried yet under linux, but was able to successfully modify their sample programs under vista after less than an hour of fiddling.

I had seen some flashes of interest in CUDA on the Quantlib mailing lists, but I’m not sure if there’s been any real follow-up.  Even if it takes some time for the open source community to get plugged-in, there are already a number of finance-oriented commercial offerings including a plugin to Matlab which allows some operations within Matlab to be offloaded to whatever CUDA subsystems are available.

If you’re comfortable with C and happen to have an nVidia card handy, I encourage you to take a look-see. The price/performance advantage is remarkable and if you have a problem that can profitably make use of it, one of these boxes might pay for itself in a big hurry!

One of these days I’m going to give an overview of all the excellent open-source software I use on a daily basis. Until that day comes, I’ll observe that finance remains one of the big areas where open-source software has made relatively limited inroads.

Two production-quality packages fight that unhappy state: QuantLib – a comprehensive framework for quantitative finance – and QuickFix – a full-featured FIX engine. Both are C++ libraries and both provide very nice interfaces to facilitate integration with other languages, including Java. QuantLib is a big and complicated library and integrating it with Java is not totally obvious. Below, I’ll describe how to build and use QuantLib from Java.

These instructions are based on a unix installation. I’m not really a windows developer and don’t have all the shiny tools that windows developers use, so it’s not an area of focus for me. That said, I have managed to build QuantLib under windows by using MinGW+MSYS but it wasn’t terribly easy and I don’t currently have a working installation, so I won’t cover that here. If this is your aim, don’t be dismayed as it is possible and it had all the functionality I enjoy under linux.

Using QuantLib from Java (on linux)

• Build QuantLib
  • Requires a working version of Boost. This may prove to be the hardest step of all and you’ll need to use the ample documentation provided by the Boost team.
  • Once you have a working copy of Boost, building QuantLib should require little more than

  sh autogen.sh
./configure

  make
sudo make install

• Build QuantLib-SWIG
  • Requires a working copy of SWIG. Again, look to the SWIG instructions, but it should be easy.
  • Once SWIG is available, building the QuantLib/SWIG interfaces should only require:

  sh autogen.sh
./configure \

  –with-jdk-include=${JAVA_HOME}/include \
  –with-jdk-system-include=${JAVA_HOME}/include/linux
  make -C Java
sudo make install

• Now you’ll have a Jar file with all of the SWIG/JNI stubs in it available in /usr/local/lib/QuantLib.jar. Add this to your classpath.
• Programs which call QuantLib functionality will need to have the LD_LIBRARY_PATH set. This can be done by invoking the vm with something like:

-Djava.library.path=/usr/local/lib

• Programs which call QuantLib functionality will also need to explicitly load the QuantLib libraries. This can be done with something like the following static block appearing before your main method:

static { // Load QuantLib
try { System.loadLibrary("QuantLibJNI"); }
catch (RuntimeException e) { e.printStackTrace(); }
}

• That’s it. Now test your configuration by running the examples in Quantlib-SWIG/Java/examples.

It’s worth understanding how Quantlib is being used from java. SWIG is creating a JNI interface into those methods within Quantlib which have been exposed through their declaration in the swig *.i files. These files are found in Quantlib-SWIG/SWIG and they determine what functionality from Quantlib will be available to you. You’ll likely need to get familiar with a subset of those files that you care about. If you find that some functionality you care about isn’t exposed in those files, you may need to expose it yourself.

There’s a learning curve, but it’s worth traversing so you can get at all the rich functionality so many smart people have put together.

I came across this article on a Go-playing program and thought it was interesting. Particularly this aspect of it (from wikipedia):

One major alternative to using hand-coded knowledge and searches is the use of Monte-Carlo methods. This is done by generating a list of potential moves, and for each move playing out thousands of games at random on the resulting board. The move which leads to the best set of random games for the current player is chosen as the best move. The advantage of this technique is that it requires very little domain knowledge or expert input, the tradeoff being increased memory and processor requirements.

This week I attended another of the excellent quant seminars I’ve written about before. This time the talk was about stochastic modeling of equity markets and was presented by Robert Fernholz of Intech. Intech is evidently a subsidiary of Janus which manages some large amount of money presumably based on some of the portfolio management theory on which Dr. Fernholz is an expert. If you visit their site, you’ll be greeted by a bigger version of their credo which I’ve, um, honored as this post’s banner: “Math is power.”

Right then. While Mao would likely have been capable of convincing me otherwise, it’s probably best for everyone involved that portfolio managers are running around with esoteric mathematical models rather than the sorts of munitions favored by 20th century Chinese revolutionaries…

My interest in the talk was largely spurred by my interest in a variant of a problem I’ve discussed here namely, how-to generate useful synthetic markets. As I’d written before, the problem isn’t impossibly difficult for a constrained set of instruments. So, generating useful models for analyzing a pair trading strategy across pairs of correlated instruments is possible and it allows you to apply option-pricing techniques to the analysis of trading strategies. Swell. But if I want to do the same thing for a portfolio management strategy that’s looking at, say, the entire US market things become more complex.

As an example, consider applying this technique to a sector rotation model. In order for the synthetic markets you generate to produce meaningful or interesting results would seem to require that you capture the behavior of how equities within a sector interrelate and also how sectors relate to one another. It gets complicated pretty quickly.

Robert Fernholz has spent many years working on this kind of problem applying tools of a mathematical sophistication I will never wield, so hearing what he had to say had to be interesting. And it was. I think. His talk was very mathematically rigorous and unless you had read and digested his earlier papers beforehand, I don’t think you’d have a great shot at following him in great detail. The high point of his talk, for me, was his sequitur following a particularly dense bunch of proofs that “…now we will leave the world of math for that of statistics”.

After he had spoken for an hour packed with dense slides showing increasingly realistic (and complex) models he stopped to field questions. A couple of the professors who had hosted the event gamely tried with a few inquiries, but the rest of the crowd blinked and emitted a stony silence and a few sideways glances meant to ascertain if they were the only ones lost in space…

While I don’t think I was deep-space-nine lost, I certainly didn’t master every point made during the talk and I don’t think I came away from it any closer to achieving my own, limited, goals wrt developing concrete techniques for applying MC simulation across so diffuse a set of instruments as a nation’s equity markets. But it did give me an appreciation for the different approaches taken to related problems.

While the extremely precise theoretical approach taken by academics is ultimately necessary, the fact that Dr Fernholz spent an awful lot of work just coming up with a model in which markets didn’t necessarily devolve to one uber instrument reminded me of one of the more distasteful characteristics of philosophy. While it may not be possible to formally prove that the chair I’m sitting on exists to the satisfaction of some kind of philosopher, it certainly isn’t profitable to argue about it.

The best way to reason about a trading strategy’s performance, that is valuing it, is as an option.

Or perhaps as a collection or portfolio of them.

I have to assume that people reading this have a working idea of what an option is, so I’m not going to provide definitions that can be readily found elsewhere. I will note that my favorite book on the trading of options is by Allen Jan Baird.

Let’s consider the three illustrative trading strategies we’ve looked at up until now. The trend-following strategy suffered many little losses and then enjoyed a big win. Sounds like buying options. The mean-reverting strategy made lots of little profits and then risked getting clobbered with a big loss. Sounds like someone who’s writing options. And the first strategy we looked at, the morning range breakout, had a payoff which looked like a long straddle or strangle where the break-evens were near the observed high and lows for the session (where we set our entry stops).

Now, there’s obvious differences between the trading strategies’ payoff structures as compared to the similar options strategies. There’s no premium, for instance, and that’s clearly significant. The morning range breakout seems to exhibit a sort of knockout effect when a position has been entered but then the market reverses and you’re “knocked-out” of your position. You just take a loss and do not collect even if the market turns back in your direction. With a straddle you don’t have this behavior. There are differences and they are worth keeping in mind. But the reasons for viewing trading strategies as options portfolios are many and compelling.

The superficial reason, as I mentioned, is that the basic payout structures are potentially similar. The deep reason is that ultimately the problems are the same – how to value complex instruments with engineered payouts. And the pragmatic reason is that many many very smart people have applied their considerable brains and diverse skill-sets to advancing options pricing techniques. There’s also a great deal of high quality software available out there which can be used to adapt these time-proven techniques to your own algorithmic trading strategy valuations.

The techniques which we’ve seen up until now, back-testing and parameter optimization, are sort of weak cousins of a family of techniques long used for options pricing: Monte-Carlo (MC) methods. MC simulation can clearly be used to assess a trading strategy’s performance.

In subsequent posts, we’ll talk about some of the details of each of these techniques and about some of their respective trade-offs. That should keep my pump primed for a bit, but in the meanwhile I leave you with a parting inquiry: what other options pricing techniques might we apply to our algorithmic trading practices?