Welcome back, and happy new year.
I hope you all had a nice holiday. I had a nice Christmas, thanks for asking; and I finally managed to find a couple of free afternoons to finish chapter 3. This post is the last in a series of seven that covered this chapter and that started with this one.
Important news: thanks to MoneyScience, and in particular to Jacob Bettany, I’ll be in London from March 24th to 26th to teach another edition of my Introduction to QuantLib Development course. It is the course that I teach based on the contents of the Implementing QuantLib book, and you can find more information, a brochure and a booking form by clicking on this link. Yes, go ahead, click: I’ll wait right here.
Done? Thanks. I look forward to see you there: I’m told London is quite nice in spring. Ok, maybe. You can probably strike that last bit.
Follow me on Twitter if you want to be notified of new posts, or add me to your circles, or subscribe via RSS: the buttons for that are in the footer. Also, make sure to check my Training page, even if you can’t attend the course this time.
Interest-rate volatility structures
Last in our tour are interest-rate volatilities. There are three different hierarchies of them, each with its quirks.
The first hierarchy models cap and floor term volatilities; the base
class is the
CapFloorTermVolatilityStructure, shown in listing 3.19.
Listing 3.19: Interface of the
It is a straightforward application of the patterns seen so far, with one main difference; the volatility is not dependent on the exercise time, which is fixed to today’s time, but on the maturity of the strip of caplets or floorlets of which the instrument is composed.
The difference is semantic:
volatility(t,strike) has for this class
a different meaning, even though the interface and the implementation
are the same as for the other volatility classes. In turn, this has a
couple of small consequences on the interface: on the one hand,
there’s an additional overload of the
volatility method that takes
the length of the cap as a
Period instance, as seemed natural; and
on the other hand, the volatility doesn’t really measure the width of
the distribution of any variable at time
t, so the
The second hierarchy models the volatilities of single caplets and
floorlets. (There are ways to convert from cap to caplet volatilities,
of course, but I won’t cover them here. Look into QuantLib for the
OptionletStripper class and its derived classes, if you’re
interested in their implementation.) Its base class is the
OptionletVolatilityStructure class, shown in listing 3.20.
Listing 3.20: Interface of the
The semantics are back to normal, with the volatility being dependent
on the exercise time. The structure of the class is as usual, too, but
with a notable addition: besides the usual
volatility method, the
class declares a
smileSection method that takes an exercise date (or
the corresponding time or period) and returns an object that models
the whole smile at that date and inherits from the base class
SmileSection, shown in listing 3.21. The interface is modeled after
that of the volatility class and shouldn’t need explanation, apart
from noting that the time is fixed and doesn’t need to be passed as an
argument to the various methods.
Listing 3.21: Partial interface of the
Simple as it seems, the addition of smile sections yields a new design that sees volatilities not as surfaces, but as collections of smiles at different times. This opens up the possibility to model the smile directly and to reuse the corresponding classes across different types of volatilities (say, for both cap/floors and swaptions).
However, we weren’t bold enough to switch completely to the new
interface. The two representations (the surface and the series of
smiles) still coexist in the base caplet-volatility class, leading to
some disadvantages. Any derived class can implement
in terms of
but this is only convenient if we’re modeling the smile to begin
with. If we’re modeling the volatility surface, instead, this design
makes it a lot more cumbersome to implement a new class. There’s no
easy way to implement
smileSectionImpl in terms of
we should return an object that’s able to call
volatility method, but that would link the lifetimes of the
smile section and the volatility surface, and in turn raise all kind
of problems. We would probably end up writing a smile-section class
that contains the same code as the volatility surface; therefore, we
might as well drop
Unfortunately, naive implementations of the
cause new objects to be allocated at each call, which is obviously not
good for performance. Smarter implementations would need to cache
objects, and with this comes more complexity. Thus, the smile section
is an interesting concept, but maybe more trouble than it’s worth. It
might be reduced in scope, and used as an implementation detail for
classes that model the smile directly.
A final note on the
OptionletVolatilityStructure class: unlike the
classes we’ve seen so far, it also declares an overload of
volatilityImpl that takes a date. It has a default implementation
that converts the date to a time and calls the other overload, so
writers of derived classes don’t need to override it; but it can
increase accuracy when the derived class takes and stores dates as
Finally, the third hierarchy models swaption volatilities; its base
class is the
SwaptionVolatilityStructure, shown in listing 3.22.
Listing 3.22: Interface of the
It has the same new features I just described for caplet volatilities
(the use of smile sections and the overload of
volatilityImpl) and a
new shtick: the additional dimension given by the length of the
underlying swap, which in turn brings a few more methods for
specifying and checking the range of the corresponding argument.
That’s all for term structures. You’ll find plenty of examples in the library; I hope this chapter will help you make sense of them.