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

lemon-law arbitrage?

Derivatives pricing has always been a notoriously complex, computationally expensive and potentially breathtakingly remunerative undertaking.  This is true enough for relatively vanilla, exchange-traded options, but once one goes off-market and starts applying creative financial engineering, it can get much more complicated.  Products like CDOs, CDSs, CDO^2s and their ilk have exploded in recent years creating opaque markets of trillions of notional dollars and accounting complexities we’re still only beginning to understand.

A recent paper, Computational Complexity and Information Asymmetry in Financial Products, by Arora, Barak, Brunnermeier and Ge take things a step or two further as they illustrate using information theory that it may be far worse than imagined as totally undetectable fraud can be engineered into these products.  They show that fraud with these products can be undetectable in the sense that the pricing process is a formally intractable problem when the informational asymmetry inherent in the development of these products is taken into consideration. In this context, “informational asymmetry” is a polite way of saying “fraud.”

The authors, from the Department of Computer Science and Center for Computational Intractability at Princeton (man, I want one of their business cards!), demonstrate that if the designer of, say, a CDO wants to cherry-pick amongst bundled assets to maximize their own return, they can do so in a way such that it would be impossible for a buyer of the derivative to know they were being stiffed.  The problem can be so hard that if you got the NSA’s mythic clusters humming on a pricing model, they might chug away until the sun falls from the sky before they accurately price it…  Co-author Rong Ge provides a FAQ to the paper here and I must hat-tip Andrew Appel for his informative post on the paper.

The “perfect crime” is a puzzle that has occupied the (criminal and otherwise) mind of many a bright and motivated soul from time immemorial.  While some may indulge towards the vulgar or base through violence or vice and others might ponder the perfect crime of passion, the cerebral Queen of Crime is surely some form of regulatory arbitrage: committing the crime for which the law has yet to be written or creatively engineering a legal loophole for a crime one has perpetrated or is about to perpetrate.  The developers of CDOs are to be lauded as it appears they have materially upped the state-of-the-art of the perfect crime.

hmmm… Is there a Nobel for that?

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.

Professor DeLong points out that Emanuel Derman has begun posting lecture notes to classes he’s teaching as part of the Columbia Master’s of Financial Engineering. If you’re even remotely interested in financial engineering or algorithmic trading, then you should read Dr. Derman’s engrossing book “My Life as a Quant” as it gives a unique and personal perspective on the explosion of engineering as a discipline within finance. I haven’t studied his notes carefully yet but a cursory examination suggests they look very worthwhile.

I recently found in my inbox an invitation to study for a Certificate in Quantitative Finance which is, I’m sure, a great program. But it’s pretty pricey and any quant should be aware of costs! Laughing in the dark might be a reasonable alternative to shelling out for a more structured offering…

There are many conceptions of our world and its underlying nature, each seemingly more creative than the last. One of my favorites – adopted by all serious fans of Star Trek as well as some physicists who’ve run rather far afoul of friar Occam’s good rule - posits the existence of a multiverse. There are various such stories, but the basic idea is that at every quanta in time the universe partitions itself off into an infinitude of parallel instances of itself, each representing a different branch of realized possibilities. In this one, I decided to become a surfer while in that one I went into finance and in that one I led the US to its first-ever world cup victory. While we only experience the particular universe we happen to be situated in, the multiverse represents the simultaneous execution of all possible universes. Under this view, we really do live in the best of all possible worlds.

This idea has surprising utility. While its cosmological implications might represent the extreme psychedelic fringe of the continuum, at the other ends lies actuarial science, the foundations of risk management and, yes, a variety of option pricing techniques.

In the universe of the simplified algorithmic trader we’ve been discussing, there are at least three ways in which this unfolding of possibilities can be considered. In the first case, we can vary the decision-making of the strategy itself; in the second, we can vary the market conditions upon which the strategy will base its decision-making and in the third case we can vary both. They are all forms of scenario analysis.

When we talk about varying the decision-making of the strategy itself, there’s a range of possible adjustments we might make. We could be speaking of actually swapping out the entire strategy itself – eg, going from a trend-following to a mean-reverting strategy. Or we could talk about changing characteristics of a given strategy. For example, to reuse our first simple sample strategy – the morning range breakout – we had a few natural “levers” or parameters which we could modify about the strategy without fundamentally changing its underlying behavior. That strategy exposed two such parameters: what to trade and how long to wait before putting its trades onto the market (that is, the length of the morning range).

If we take this idea of permuting a strategy by way of its parameters and combine it with the idea we discussed last time and back test each of these permutations, we arrive very close to the idea of parameter optimization of a strategy. The only missing piece is the idea of ranking the results of each of these strategies. This turns out to be somewhat more complicated than it might appear and we’ll consider it in a later post.

Assuming a simple case where we disregard risk management practices and simply rank the strategies by return on investment (ROI), we can see that parameter optimization is a bit of a misnomer as we’re not so much optimizing the strategy as we are searching for the best strategy within a set of strategies defined by the ranges of each of the parameters we’re considering. This is at best a weak form of optimization and is perhaps better characterized as a search problem.

Before considering the utility and limitations of this kind of parameter optimization we’ll next take a look at the second form of scenario analysis in which instead of permuting the strategy by way of its parameters, we change the market conditions in which the strategy operates. This will be the topic of our next post.

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?