Remember me

Register  |   Lost password?

Introduction to QuantLib Development - Intensive 3-day Training Course - September 10-12th, 2018 - Download Registration Form Here


MoneyScience Blog Header 2015 2

Open Source Finance 1. QuantLib - An Interview with Luigi Ballabio

Sun, 03 Mar 2013 06:38:00 GMT

Luigi BallabioIn this interview we talk to Luigi Ballabio about QuantLib, a free software framework for Quantitative Finance which he has been involved with since it's original launch in the year 2000. Luigi currently participates in the design, maintenance and development of the core C++ library for QuantLib, including the review and management of the contributions from users. In his day job, Luigi is Senior Quantitative Developer at StatPro Italia where he designs and implements the C++ financial libraries used in the StatPro Risk Management (SRM) and Complex Asset Pricing (CAP) applications.

In this interview, Luigi also talks about his 3-day training course, Introduction to QuantLib Development, which is next due to take place in London, 29 June - 1st July 2015 and costs £1800 per person + VAT. You can Download a Brochure and Registration Form for the Course here (pdf).

Jacob Bettany: Can you tell me a little bit about your background and how you came to be involved in the QuantLib Project?

Luigi Ballabio: It seems like a lifetime ago but I started out as a physicist, I used to work on Nuclear Fusion - well not Nuclear Fusion per se. I was on a team that was building diagnostics for reactors, so I guess even at that time, I was building tools instead of using them. After that I was dragged into quantitative finance by a couple of school mates who were already working in finance, in a bank in Milan. Everything came together when I was finishing my Ph.D. in Uppsala, in Sweden. I was looking into coming back to Italy but it was hard to do as a physicist, and much easier to get a job in Finance, so I started at Caboto, the investment bank of Banca Intesa with one of the other founders of QuantLib, Ferdinando Ametrano, I worked there for one and half years or so, and moved to the company StatPro Italia which at the time was called RiskMap, and that was when we started QuantLib.

JB: And how did QuantLib come about originally?

LB: Well I can't take much credit for that actually. I had just started at RiskMap, which itself has just started as a company. It was founded by Dario Cintioli, who had been the head of the interest rate desk at Banca Intesa. We came to work for him and it was just 3 or 4 of us at the time, plus Dario, and we were faced with the prospect of starting to write code all over again. It was Ferdinando who had the idea. He thought that since we had to write the pricing code all over again, we might as well do it as an Open Source project. One idea was that since we were a small company this might be a way of getting ourselves known.

So Ferdinando had the idea and we discussed it for a while but it was Dario who had the courage to take the idea and to run with it. We started in Autumn 2000 with the first release which was a small one obviously and we announced it on some mailing lists and forums we knew.

It was just us to begin with, Ferdinando and I, and a couple of others at RiskMap, Marco Marchioro and Adolfo Benin and later a few others such as Enrico Sirola and Mario Aleppo. After a while it started picking up steam and started getting the first contributions.

The original email from 2000 announcing the QuantLib project.


JB. That must have been quite exciting I imagine, and quite an exciting period generally. So in those early days, when you were contributing much of the original code, was there a plan you were following, or did it evolve rather organically?

LB: We had an idea of what kind of things we needed to begin with, but it was mostly the basics. We knew we would need a date and calendar library for instance, and that eventually we would need, say, Monte Carlo simulations, but mostly it was driven by what we needed in our day-to-day work. We came from an interest rate background so we started with term structure bootstrapping and as we had to cover different products, we moved on to different modules.

JB: So I guess when people started contributing, it was to cover their own requirements?

LB: I don't remember the first contributions right now. I think one of them was the infrastructure for building QuantLib on Linux, which was useful as we had only been working on Windows machines until that time.

JB: And right now, as opposed to historically, I guess the contributions come from a very variety of practitioner backgrounds?

LB: I think so. I don't know exactly how wide, but we had contributions from people working in Credit Derivatives, interest rates, inflation bonds... we also get contributions from people in academia, which is quite nice as this was one of the original goals for the library - to make it useful for both environments.

JB: In terms of the future, is there a roadmap now, or do you expect it to continue evolving organically?

LB: Well there are a few things I'd like to tackle, but I'm not yet sure about the best way to do it, and they are mostly technical issues. I think the biggest single limitation right now is that we are moving towards a parallel processing, multi-core environment and Quantlib isn't really suited for that.

I mean we started in 2000 and the trend toward parallel programming wasn't in full swing yet, we were in the period when processors kept increasing in speed so it wasn’t really a concern back then, so the architecture is single threaded and there are a number of things in there which make it difficult to use in a multi-thread setting.

QuantLib is written in C++ with a clean object model, and is then exported to different languages such as C#, Objective Caml, Java, Perl, Python, GNU R, Ruby, and Scheme. The QuantLibAddin/QuantLibXL project uses ObjectHandler to export an object-oriented QuantLib interface to a variety of end-user platforms including Microsoft Excel and OpenOffice.org Calc. Bindings to other languages and porting to Gnumeric, Matlab/Octave, S-PLUS/R, Mathematica, COM/CORBA/SOAP architectures, FpML, are under consideration.

That's the main thing I'd like to address, but I'm not an expert in that field myself so we would need to get advice from users with more experience of those kind of calculations.

On the other hand, it would mean we would need to change a number of interfaces in the library and rewrite some parts of it, which would mean a 2.0 version of the code. Since version 1.0 we made sure that if someone wanted to upgrade from 1.0 to 1.1 for instance, a user wouldn't have to change their own code, we ensured backward compatibility. In this case we would be forcing people to upgrade, breaking that compatibility and would need to think hard about how to do it. We'd probably have to say, users be aware, this is version 2.0, you may have to change your code, but we'd thinking of ways to make the transition smoother and less painful. Clearly it's going to take time and personally I've been less involved in development and more in reviewing contributions, adding them to the library and that kind of housekeeping for the last few releases.

JB: It occurs to me that you could create a brand new product couldn't you? Could you fork it?

LB: Yes. The problem with keeping two versions is that it doesn't quite double the effort to manage the project, but certainly increases it.


JB: You already touched on this, but what are the other limitations in QuantLib?

LB: One thing I’ve been thinking about for a while, is related to the fact that there is a preferred way in which QuantLib should be used. It has a very particular architecture and if you go against the grain you have to work around a number of things. It's good in that gives you flexibility to build on top of existing functionality. The other side of the coin is that even for simple things you bring with you quite a bit of luggage. One thing that always bugs me; take the Black-Scholes formula, which is the most basic in a Quantitative Finance library, if you look for it in QuantLib you'll find no single, simple function which gives you the Black-Scholes price for an option. There are objects which give you the price, even if you don't instantiate the full instrument, but still I would like to have a simpler function which is formalised in the architecture. In general, I would like to have a functional core which is then wrapped with the more complex functionality. This might be simpler than the parallel processing problem and we'll see if I can find the time - though of course if someone reading this would like to step up to the plate, that would be welcome!

JB: This question may seem fairly obvious to you, but perhaps not necessarily to everyone who is reading this. Can you talk a little bit about the way QuantLib is actually used in practice in financial institutions?

LB: The funny thing is that I don't have much data about that. I've been in a couple of places myself where people use QuantLib but it difficult to tell how many are using it in a production environment. I mean, I see thousands of people subscribed to the mailing list, with many subscribers from big name institutions, and I see thousands of downloads every time we put out a new release but people doesn't tell, and there's just not that much data around on actual practical applications, or whether people use it in production (or part of it, I hear from some people that they're not using the whole thing, but for instance reuse our date library with what they already have). Other people might have their own code and be using QuantLib as verification to see if their numbers are in the same ballpark.

I have seen it in production in a few places I'm not sure I can name, and I've seen it used on university courses, (I've been invited myself as a guest lecturer), but most of the users are shrouded in mystery!

JB: So I'm quite glad I asked that question now! So let's turn briefly to the training event that you're going to be running with MoneyScience. Perhaps you could explain a little bit about what the event covers in general.

LB: We begin by covering the general architecture of the library. As I said, for good or for bad, the library is written to be used in a certain, preferred way, so I cover the design of the library and the implications that has for coding with it. That's day 1.

On the 2nd and 3rd day, I cover 2 frameworks which can be used to build pricing code on top of the general architecture, Monte Carlo simulations and the framework we have in place for binomial and trinomial trees, which I think is the right content for 2 days. Last time we did the course it would have been hard to squeeze more in.

JB: And what kind of exercises do you undertake with the delegates?

LB: On the first day, we play with the architecture a little bit so for instance we take a simple formula for the pricing of an instrument, we insert it into the architecture and see what this produces and how it behaves. On day 2 and 3 we do more extensive exercises building pricing code for new financial instruments. On day 2 we create a bond with a payoff dependent on the performance of a basket of underlying assets using a multidimensional Monte Carlo simulation. For the tree framework, on day 3, we build a range accrual bond using trees for simulating the interest rate. It takes longer than you expect! Each day I spent half presenting the framework, and the other half on the exercise itself. The exercises are very interactive.

JB: In terms of minimum requirements for the course, what level of experience do people need to participate on the course? And what do people actually need to bring with them?

LB: There are 2 aspects, the financial side and the programming side; on the financial side, the course doesn't require a great deal of previous knowledge, I'm not going into cutting edge math finance, I think as long as you understand basic finance you'll be okay.

In terms of the programming, you'll be bringing your development environment and a compiled version of the library with you. You will need some proficiency with C++ because for time reasons I'm not able to go into all the features of the language that we are using. I will explain those which are less commonly used, so if we have, say, some template metaprogramming, I'm going to explain what happens in there.

All of that said, I've probably made it sound scarier than it actually is!

JB: Thank you very much for your time, Luigi. It was great to talk.

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,