QuantLib in 2020 and beyond
Welcome back.
I’ve never been one for plans, so I probably have no business writing a post on what we might expect from QuantLib in the next year or two—especially since it’s driven by contributions by volunteers. Yet, here we are. In this post, I’ll list a few things I’ll try to work on, or that I’d be happy for enterprising people to pick up.
New risk-free rates
The first one is kind of obvious, and in fact, there’s already been
some discussion on the QuantLib mailing
list
about this. We should cover instruments paying the SOFR, ESTR and
friends, which we kind of support but not explicitly. We have
classes such as
OvernightIndexedCoupon
,
which compounds overnight fixings over the life of the coupon, or
OvernightIndexFutures
, which currently acquired the
ability to
perform averaging as well as compounding, as required by 1-month SOFR
futures. However, we should probably reorganize and abstract out the
code that performs the averaging and/or the compounding, so that it
can be reused across instruments. It might be a set of functions or
some class, depending on how we choose to model it. If you want to
have a shot at it, by all means open a pull
request.
Inflation-based instruments
After using it for a while, a few things in the current implementation of inflation rates have started to seriously irk me (I had noted some of them already in Implementing QuantLib.
One is the fact that inflation term structures take a discount curve as a constructor argument. I started to do something about this by passing the discount curve to the relevant pricing engines instead (so they can stop relying on the one in the inflation term structure) and deprecating their other constructors. Once they are removed, probably in version 1.19, we can start doing the same to the inflation term structures. Unfortunately, it’s going to be slow work due to backward compatibility.
More irksome, though, is the existence of two separate
ZeroInflationIndex
and YoYInflationIndex
classes.
I agree that we might need different classes to forecast zero rates
and year-on-year rates, but there’s no such thing as a year-on-year
HICP index; there are instruments that pay the year-on-year
performance of the HICP index, and that performance is not an index
fixing in itself. We should have just one index hierarchy.
By the same reasoning, there is no interpolated HICP index as opposed to a non-interpolated one. That index fixes monthly; different instruments might calculate their payoff by interpolating between fixings, and they should not delegate the calculation to the index itself (which, in the current implementation, delegates it in turn to the underlying term structure, making it even worse).
(A note: I’m definitely not meaning to disparage whoever wrote that code. It was 10 or 15 years ago, the architecture at that time was not clear, and they—we, since I probably had a hand in that— did the best they could. But now that we know better, I’d like to change the code to reflect the new understanding.)
C++11
I’ve written a bunch of posts about my experiments with leaving C++03, and given that C++20 was recently approved, it might be time do to something about it and adopt at least C++11. The one thing holding us back is compiler compatibility; we’ll need to require at least Visual Studio 2015 to have decent language support, so it will take a few versions to deprecate and drop support for earlier versions. QuantLib 1.17 deprecated VS 2010; later releases will deprecate VS 2012 and 2013, but it will probably take a year or two before we do the jump.
Once we do that, we’ll probably switch from some Boost classes we’re
using (such as shared_ptr
or function
) to the corresponding std
classes—which, by the way, is already possible if you choose to
do so. At that
point, it might be worth determining what other Boost code we use, and
if there’s any possibility of removing the dependency on Boost
altogether.
Contexts
This is an old one; I wrote about it in Implementing
QuantLib
when I described the global Settings
class, and before that I
talked about it at the QuantLib
User Meeting in 2013, so I’ll put it very shortly here. I’d like to
replace the existing globals, but I don’t have yet an idea of how to
do it. I’ll be grateful for any suggestion.
Libor Market Model
I’ll be frank: I would see this as a kind of tribute to Mark Joshi, who passed away in 2017 and who led the effort of writing our current implementation of the LMM model. That part of the library still needs to be brought together with the rest of the architecture by providing the means to use it in pricing engines. I’d love for that to happen.
Anything else
The above is just a list of a few things I’d like to see; and of course, I’m probably overlooking other stuff, and I’ll be as happy and as grateful as usual to accept other contributions. You’ve been great during these past 20 years, and I’m sure you’ll keep being great during the years to come.
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.