selective model calibration
Locked
 
|
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 |
Re: selective model calibration
|
|
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 |
Re: selective model calibration
|
|
Hi Roland, actually the third case is my core motivation since it seems not really possible to keep only the first component of a piecewise parameter fixed during calibration. A workaround is possible also in this case, but it is really ugly.
Concerning the second case I observed that calibrating a Hull White Model with piecewise volatility to 1y/34y, 2y/33y, ... 34y/1y at the money coterminal swaptions (the reversion being fixed) takes significantly longer using a 34-dim Levenberg-Marquardt optimzation compared to 34 1-dim optimzations or zero searches. I can send example code, however it relies on a not yet officially released implementation of a GSR model (as described by Piterbarg). Up to now I added a "calibrateIterative(...)" - method to CalibratedModel as a workaround, but you have to consider in which situations this will work correctly before applying it. It would be much nicer to have a robust implementation in the GSR model itself, where you can take care of executing the procedure correctly just by invoking the base class method for each option and fix the respective components in each iteration.
Do you still think example code for the second case would be useful (then I will prepare something you can pull) or can you run a test like the one above easily on your side as well ? I think the general solution will not require much coding, so I will give it a try on the weekend. regards Peter
On 24 October 2013 10:36, Roland Lichters <[hidden email]> wrote: Hi 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 |
Re: selective model calibration
|
|
In reply to this post by Roland Lichters-2
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 -- <https://implementingquantlib.blogspot.com> <https://twitter.com/lballabio> ------------------------------------------------------------------------------ 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 |
Re: selective model calibration
|
|
this is even better ! thanks a lot Peter On 24 October 2013 11:30, Luigi Ballabio <[hidden email]> wrote: Yes, it sounds interesting. I would add the extra vector parameter to ------------------------------------------------------------------------------ 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 |
Re: selective model calibration
|
|
In reply to this post by Luigi Ballabio
Here is what I'd suggest.
https://github.com/lballabio/quantlib/pull/48 Everything 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 |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |