Hack the market

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

EMS Internals, dereferenced, monte-carlo methods, open-source software, options pricing, technology

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.

books, dereferenced, monte-carlo methods, strategy development

While the war over the latest+greatest video cards for the current generation of graphics intensive games seems always to ebb and flow between nVidia and its arch-rival ATI, I’ve long preferred nVidia for their better support of Linux.  Thus, all of my machines have some sort of nVidia Graphics Processing Unit (GPU) in them.

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…

Read more…

monte-carlo methods, options pricing, portfolio management, technology

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.

FIX Protocol, monte-carlo methods, open-source software, options pricing, technology

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.

dereferenced, monte-carlo methods, technology

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…

Read more…

events, monte-carlo methods, portfolio management

It turns out that one can actually sculpt or engineer randomness. Further, this ability can shed remarkable light on otherwise mysterious phenomena – like the value of an option or the performance of a complex trading strategy. The applet above is governed by the equation (for Geometric Brownian Motion) below. It provides you with the ability to produce a random stream with three modifiable characteristics: an initial value (in this case fixed at 100), volatility (or ‘diffusion’) and expected return (or ‘drift’ or slope). Every five seconds it will generate a new path based on the current settings. Hopefully, this applet provides a little insight into the machinery of a powerful algorithmic trading tool: monte-carlo methods. Read more…

EMS Internals, monte-carlo methods, open-source software, performance analysis

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?

back-testing, books, monte-carlo methods, open-source software, options pricing, performance analysis, strategy development, technology