This is the third in a series of posts on chapter 5 of my book; Part 1 and 2 are here and here. It is still being written as you read, which brings novelty, excitement, and the possibility that I fall behind the schedule. We’ll see how this turns out.
From the 2nd to the 4th of September I’ll be in London to teach my Introduction to QuantLib Development course. One of those nights I’ll go grab a pint or two with a few people; drop me a line if you want to join us. Assuming I find a data connection, I’ll try and tweet the place. (And yes, places for the course are still available; go to this link if you’re interested).
Parameterized models and calibration
There is an ambiguity when we say that a model has a given number of parameters. If they are constant, all is well; for instance, we can safely say that the Hull-White model has two parameters alpha and sigma. What if one of the two was time-dependent, though? In turn, it would have some kind of parametric form. Conceptually, it would still be one single model parameter; but it might add several numbers to the set to be calibrated.
Parameter class, shown in listing 5.3, takes the above into
account—and, unfortunately, embraces the ambiguity: it uses the
term “parameter” for both the instances of the class (that represent a
model parameter, time-dependent or not) and for the numbers underlying
their parametric forms. Our bad: you’ll have to be careful not to get
confused in the discussion that follows.
Listing 5.3: Sketch of the
Specialized behavior for different parameter will be implemented in
derived classes (I’ll show you a few of those shortly). However, the
way we go about it is somewhat unusual: instead of declaring a virtual
method directly, the
Parameter class is given an inner class
which declares a purely virtual
value method. There’s method in this
madness; but let me gloss over it for now. (Someone on the Wilmott
forums suggested that the reason is job security: if we obfuscate the
code enough, nobody else will be able to maintain it. I can see his
point, but this is not the reason.) The idiom is used in other
classes, and will be explained in appendix A.
Parameter represent, in principle, a time-dependent
parameter and store an array
params_ which contain the values of the
parameters used to describe its functional form. Most of the interface
deals with these underlying parameters; the
params method returns
the whole array, the
setParam method allows to change any of the
values, and the
size method returns their number.
Parameter instances also store a constraint that limits the range of
values that the underlying parameters can take; the
provides the means to check their current values against the
operator() returns the value of the represented
parameter (I’m not sure how I should call it. The main parameter? The
outer parameter?) as a function of time, given the current values of
the underlying parameters; as I mentioned, the actual implementation
is delegated to the stored instance of the inner
Finally, the class declared a couple of constructors. One is
protected, and allows derived classes to initialize their own
instances. Another is public; it creates instances without behavior
(and therefore useless) but allows us to use
containers such as
std::vector (I think this is no longer necessary
in C++11, but we are still living in the past).
Listing 5.4 shows a few examples of actual parameters; they inherit
Parameter class and declare inner
Impl classes that
Parameter::Impl and implement the required behavior.
Listing 5.4: Sketch of a few classes inherited from Parameter.
The first represents a parameter which is constant in time; this is
what we usually think about when we talk of a parameter, and is
possibly the most used. The array of internal parameters has just one
element (as seen by the 1 passed to the
Parameter constructor), and
that’s what the implementation returns independently of the passed
The second is a null parameter; its value is supposed to be 0 and must
not be calibrated. In this case, the stored array has no elements
(again, see the 0 passed to the
Parameter constructor) since nothing
will move during calibration. This could probably be a specific case
of a more general
FixedParameter class, whose fixed value could be
different from 0.
Finally, the third class represents a time-dependent parameter. It is modeled as piecewise constant between any two consecutive times in a given set; thus, if the set has \( n \) times, we’ll have \( n + 1 \) different values (including the one before the first time and the one after the last). The implementation is a simple linear search, as we don’t expect the times to be too many or we’d be likely to over-calibrate.
The library implements other parameter classes (and we could define others; for instance, using other parameterizations of time dependence) but I won’t keep you any longer. At this point (that is, in next post) we need to turn to the class that—I don’t really have a less awkward way to say it—models a calibrated model.