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

As I’ve written before, I’m not a particularly big fan of technical analysis or any of the many and varied charting techniques people espouse.  That said, we are working with a proprietary futures trading company and some of the successful (non-algo) trading that they do involves point-and-figure charts.  Although a trading algorithm doesn’t care about graphical representations, I wasn’t familiar with the technique and decided that the best way to understand it was to try to implement it, which is how I spent my Saturday evening …

The above applet re-uses the one I’d written previously in discussing simple stochastic processes.  This time, it illustrates a point & figure chart below the regular line chart.  Point & figure charts expose two characteristics: a “box size” (in ticks) and a “reversal” (in boxes).  The applet allows you to vary both and then generate a day’s worth of random/synthetic data to view it.  One of the nice features of JFreeChart is that you can easily “zoom” into a chart by dragging within the chart.  I’ve disabled this in the line chart but you can try it in the p&f chart.  (Note: you should right-click and “Auto-Range-Both Axes” before you generate new data or you’ll stay in the zoomed segment of the chart.)

Now that I think I understand the basics of point & figure charting, it will be interesting to see what an algo might do with it…

One Big Table (and chair)

Last time I described the trajectory of my research into using hdf5 for large amounts of tick data.  This time I describe the basic design of the prototype I implemented and some of its performance characteristics.

Read more…

One of the nicest things about the holiday season (Happy New Year, btw) is that it provides a lovely opportunity to spend some quality time with a project that’s a bit more exploratory than might be meaningfully undertaken while trading in lively markets.

A number of months ago, I mentioned using HDF5 to manage tick data as RDBMSes just aren’t up to the task and specialized Tick DBs are absurdly expensive.  While I’d spent some time exploring this idea through the fall, I never had a discrete chunk of time to really explore the technology beyond determing that its Java interfaces weren’t production-worthy.  This meant that we’d have to drop into C to access the functionality we’re interested in and that we’d have to come up with our own bridge out into Java for access by StratBox while StratCloud could access it directly.

Below, I describe what I’ve learned through my holiday geek-spelunking-trek including some timings on various configurable characteristics of HDF5 (e.g., compression and “chunking”).

Read more…

Normally I spend my design-oriented thoughts on object models – when I’m working on StratBox  – or about volatility, latency, executions, &tc – when I’m working on a trading strategy.  But a recent trip abroad has inspired me to consider more fanciful design horizons.

After more than a year of blogging I’ve finally decided to refresh the look of the site and you’re looking at the first iteration of this effort.  Blogging software is pretty remarkable as it allowed me to essentially change the “skin” of the blog without affecting its content.  This is like Kirill Grouchnikov‘s lovely open source “Substance” Look&Feel for Java which does the same trick for swing-based applications: just include his magic code and your system automagically looks a lot better!

More substantively, my recent trip to Israel and the subsequent agreement to open a Tel Aviv office to take advantage of a felicitous new partnership and Israeli algorithmic talent, has led to a broadening of our mission.  This in turn led to the foray into graphic design I describe below. Read more…

While Carl Sagan’s famous formulation introduced a generation to the vastness of the cosmos, more recent history suggests that his memorable term might now be more aptly applied to financial extents: our deficits and debts, perhaps, to the economically or politically minded. But for those of us with the markets on our mind, the term has to evoke the enormity of the data we create and must manage every day. We’ve recently been working with the NYSE’s TAQ data in an effort to integrate it into StratBox‘s back-testing and optimization capabilities. And the enormity of the data is really just staggering.

Each day, the NYSE publishes all of the day’s quotes and trades as well as some reference data. Compressed, the data will just about fit onto a DVD. For one day. A DVD. Compressed. It’s really mind-boggling. A year of the stuff, uncompressed, will require over a petabyte of storage. Over 1,125,899,906,842,624 bytes. And that’s just the US Equities markets. You want options data, too? I hope your uncle is named EMC, because just managing the data is going to be a challenge…

Read more…

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.

Among the more challenging questions we face when describing the Puppetmaster environment are those like “how do you create new proprietary trading strategies within the environment?” It’s a difficult question because of expectations – people want to hear about some super simple scripting language that any non-technical person can immediately learn and be up and algorithmically trading in no time. A few platforms intended for retail users offer such things – one is even appropriately named easy language. When researching approaches for our system, we spent some time learning easy language and found that it in fact did make easy things easy!

The problem was that it also made sophisticated things impossible.

This led us to pursue another, more powerful, approach for which we are currently seeking a patent.

Read more…

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…

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?