selective model calibration

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

selective model calibration

Peter Caspers-4
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
Reply | Threaded
Open this post in threaded view
|

Re: selective model calibration

Roland Lichters-2
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
Reply | Threaded
Open this post in threaded view
|

Re: selective model calibration

Peter Caspers-4
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,

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
Reply | Threaded
Open this post in threaded view
|

Re: selective model calibration

Luigi Ballabio
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
Reply | Threaded
Open this post in threaded view
|

Re: selective model calibration

Peter Caspers-4
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
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
Reply | Threaded
Open this post in threaded view
|

Re: selective model calibration

Peter Caspers-4
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