Posted by
Peter Caspers-4 on
Oct 26, 2013; 9:56am
URL: http://quantlib.414.s1.nabble.com/selective-model-calibration-tp14610p14617.html
Here is what I'd suggest.
https://github.com/lballabio/quantlib/pull/48Everything should be backward compatible except for a different default
behaviour of the markov model, which gives a better fit to the secondary
calibration instruments now, see below.
>From the end user perspective it is e.g. possible to write
model->calibrate(swaptions, optimizationMethod, endCriteria,
Constraint(), std::vector<Real>(),
HullWhite::CalibrationConstraints::FixedReversion());
and only calibrate the volatility while kepping the reversion fixed on
its initial value.
The second application is for the markov model where I added a constraint
FixedFirstVolatility(), which I also made the default constraint by
overwriting the calibrate function in the markov class itself. One
should set a volatility step date on each secondary calibration
instrument expiry (different from a piecewise Hull White model for
example where you usually leave out the last expiry). The first
volatility only gives the scaling of the volatility vector and can be
set to 0.01. See the updated test case for an example.
It should be easy to add similar constraints to other models.
Note that I follow the convention in ProjectedCostFunction where true
means that a parameter is fixed and false that it is free (which
confused me a bit).
A little complication was that we do not only need a projected cost
function, but also a projected constraint. Therefore I abstracted out
the projection part which is now used by both ProjectedCostFunction and
ProjectedConstraint. The CalibrationFunction directly uses Projection
and not the projected cost function. I tried the latter first but it
produced code that looked slightly strange.
I added a test case for the HullWhite example and amended the markov
test case.
It would be great if you could have a look and try to adapt your own
model code to the new design and see if it works for you too.
Thanks a lot, see you
Peter
Luigi Ballabio <
[hidden email]> writes:
> Yes, it sounds interesting. I would add the extra vector parameter to
> calculate();
> derived classes might provide functions that return predetermined vectors, e.g.,
>
> model->calibrate(helpers, ..., HullWhite::constraints::keep_reversion_fixed())
>
> or
>
> model->calibrate(helpers, ...,
> HullWhite::constraints::move_single_volatility(i));
>
> or something shorter, of course :)
>
> This way, derived classes wouldn't even have to override calibrate().
>
> Later,
> Luigi
>
>
>
> On Thu, Oct 24, 2013 at 10:36 AM, Roland Lichters
> <
[hidden email]> wrote:
>> Hi Peter,
>>
>> that sounds interesting and useful. I keep coming across your first
>> case, and I solved it so far by passing a vector of booleans to the
>> model constructor and setting up calibration params and indices to
>> them accordingly, in each model constructor, without changing
>> QuantLib. It is not elegant, but one can select which part of the
>> parameters are calibrated and avoid dealing with various copies of
>> the model. I'd be curious to see whether this can be achieved with
>> less coding when we change QuantLib as you suggest. Your second case
>> didn't even occur to me yet.
>> Can we have a look at a code example? I am also happy to share my pedestrian approach if of interest.
>>
>> Regards,
>> Roland
>>
>>
>> On 23 Oct 2013, at 21:37, Peter Caspers <
[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> I would like to be able to calibrate only a subset of the parameters
>>> of a CalibratedModel instance. Even more I would like to fix a subset of
>>> elements within one multidimensional parameter in some cases. With this
>>> one could e.g.
>>>
>>> - calibrate both reversion and volatilities or fix the reversion and
>>> calibrate only volatilities in a Hull White model
>>>
>>> - calibrate the model volatilities in a Hull White model iteratively to
>>> single interest rate options with ascending option maturities instead
>>> of having to do a global calibration to the whole set (which can be
>>> much slower when you have many options in the calibration basket)
>>>
>>> - easily avoid the redundancy in the piecewise volatlities of a markov
>>> model (multiplying the volatilies by a (non zero) scalar factor does
>>> not change the model up to numeraire recalibration)
>>>
>>> There are probably more use cases. I guess there are workarounds for
>>> most of these cases, but I would like to propose a solution in the
>>> CalibratedModel class itself. Since I am not sure about the design I am
>>> not just sending a pull request but would like to discuss the approach
>>> first. Here is what I would try:
>>>
>>> Add a parameter to the calibrate method specifying the free parameters
>>> in a vector<bool> and defaulting to an empty vector meaning all
>>> parameters are free. Within the method one can make use of the
>>> ProjectedCostFunction then to easily get what we want. One could also
>>> make this calibrate method protected and leave the public interface as
>>> it is, just invoking the new method with the default for the new
>>> parameter. That is probably better because on the level of the
>>> CalibratedModel one does not know the meaning of the parameters and
>>> of their components.
>>>
>>> Again in the protected section, provide an inner class that allows to
>>> construct the above vector<bool> conveniently from specifying parameters
>>> to include or exclude or indices within a parameter to include or
>>> exclude in or from the set of free parameters.
>>>
>>> This does not change anything so far. However derived models can now
>>> easily overwrite the calibrate method (which we would have to make
>>> virtual) and do a specialized calibration as needed / specified in the
>>> concrete models.
>>>
>>> What do you think ?
>>>
>>> regards
>>> Peter
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>>
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk>>> _______________________________________________
>>> QuantLib-dev mailing list
>>>
[hidden email]
>>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk>> _______________________________________________
>> QuantLib-dev mailing list
>>
[hidden email]
>>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev