The QuantLib ecosystem

Hello again!

Today’s post was originally published in the November 2024 issue of Wilmott Magazine. So far, it’s the last of my columns there. You can find the full list of articles on my Tutorial page, together with the corresponding source code when available.

Subscribe to my Substack to receive my posts in your inbox, or follow me on Twitter or LinkedIn if you want to be notified of new posts, or subscribe via RSS if you’re the tech type: the buttons for all that are in the footer. Also, I’m available for training, both online and (when possible) on-site: visit my Training page for more information.

The QuantLib ecosystem

Welcome back! In my previous articles, I tried to look at QuantLib from a number of different perspectives such as features, usability, design, or extensibility.

In this article, I’ll widen my net and list a number of satellite projects and ports in other languages which spawned from QuantLib (mostly through no effort of ours, I must say.) Let’s have a look.

Different languages, same library.

The same C++ library we know and love can also be called from other languages through bindings. We officially provide some of those: others are independent efforts.

Official bindings

If you happened to read my article from the September 2023 issue of Wilmott, or if you bought the QuantLib Python Cookbook, you already know that QuantLib can be used from Python and interact with Jupyter and the rest of the language’s impressive ecosystem. If you’re a Python user and you don’t need to modify the library, you don’t even need to compile it; it’s already available on PyPI.

What if you prefer another language? And by “prefer”, of course, I mean that the rest of your system is implemented in another language, or that the expertise of your development team leans that way. Well, SWIG (the same program we use to semi-automatically generate the Python bindings) can also be used for other languages; currently, we support two enterprise languages, C# and Java, and a more niche one, R. As for Python, a precompiled C# binary is available on NuGet; you’re welcome to try it and report any problems on the QuantLib mailing list.

If you want to use QuantLib from Java, I’m afraid you’ll have to compile it; and you’ll have to pass a compiler flag that enables a thread-safe implementation of the Observer pattern, because (as I mentioned in passing in the November 2023 issue; see how everything comes together?) the garbage collector might otherwise interfere.

Bindings for an older version of QuantLib are also available for the most used functional language of all—Microsoft Excel. Their maintainer (hi, Eric) did an excellent job making it possible to use an object-oriented library from a spreadsheet. Unfortunately, the project is currently dormant and could use some help because, well, life doesn’t always give one a chance to maintain an open-source project. For the record, I’m forever grateful to my employers for giving me some company time to do it.

Unofficial alternatives

The advantage of using SWIG to generate bindings is that the same set of input files can be used for different languages. The disadvantage is that using the same set of input files gives you little leeway to tailor the interfaces for idiomatic language use.

A few projects address this issue by providing alternative idiomatic bindings for a single language each.

First and eldest, RQuantLib provides idiomatic bindings for R and is available via CRAN. It also provides a nice example of serendipity, because RQuantLib spawned a much more relevant package for the R ecosystem: Rcpp, which can be used to integrate C++ code into R and is currently used by over 2500 packages on CRAN.

Also for R and from the same maintainer (hi, Dirk), the lighter-weight qlcal project provides just the calendaring functionality of QuantLib. You might remember that I already mentioned it in the January 2024 issue. Do you see a pattern here? Pick up your back issues of Wilmott or hit my site.

In the Python camp, PyQL provides more idiomatic bindings by using Cython, a tool specialized for the language. This makes it easier to support niceties like keyword arguments and snake_case method names (as opposed to the camelCase names we have in the C++ library.) Like RQuantLib, PyQL provides fewer classes and methods than the official bindings are able to support. As a general rule, all the open-source projects I’m mentioning in this article will be glad to have your help if you’re so inclined.

Different languages, different library

Other projects tried to avoid the impedance mismatch between C++ and their target language by porting the library rather than wrapping it; that is, by rewriting it in the target language. A few of them are listed on the QuantLib site. By using the target language directly, they are able to integrate better with it and to use its existing patterns and facilities.

Not surprisingly, though, it’s difficult for them to keep up with the sheer quantity of code in the original QuantLib. One port that seems to have reached critical mass and to be still developed is the C# port, called QLNet; the Java port JQuantLib also has decent coverage but seems to have been dormant for a while.

Same library, different types

A long time ago, in a rare display of foresight, we hid native C++ types behind a few typedefs; for instance, we added Real as an alias to double, or Integer as an alias to int. These typedefs give us the possibility to redefine the types we’re using in the whole code with a single localized change.

Our thinking at the time was that one might have wanted to replace the default double with, say, long double for added precision, or float for higher speed. As often happens, we were wrong. But it all turned out fine in the end, because in more recent years this provided the required hook for adding Adjoint Algorithmic Differentiation (AAD) to the library.

The idea (which I’m oversimplifying here) is that by replacing the built-in double type with an instrumented class that overloads arithmetic operators, it’s possible to keep track of a given calculation and provide simultaneously the result and its derivatives with respect to all the input variables, without changing the existing code and with a cost in performance which is a lot less than the cost of getting the same derivatives by bumping the inputs and redoing the calculation.

The first implementation of the idea was provided a few years ago by CompatibL, and now seems dormant. Nowadays, there are two very active implementations by Matlogica and XAD (in strictly alphabetical order), both of which provide other goodies besides AAD.

A lot more of the same

Finally, another project builds on QuantLib and adds more complex functionality. The Open-Source Risk Engine, or ORE for short, is a number of things. It contains a recent version of QuantLib, extends it with further instruments and models, and wraps it in an application through which you can provide your input market data and portfolio specifications and perform tasks such as exposure calculation and XVA.

A note: the people behind ORE would be completely cool about taking some of their additional instruments and adding them to QuantLib, but like all of us they’re short on time to do it themselves. Again, help would be appreciated.

See you next time!