Question on extrapolation method in term structure classes

[Michelotti Enrico]

Hello all,
We have a problem in setting the extrapolation method
in the term structure class (and derived classes) in case
we use it to calibrate some models.
For instance: suppose we have a market swaption volatility matrix
by which we want to fit the best HW parameters (or onother model as well).
Within this matrix we have volatilities related to
30y swaptions on 30y swap. So the total implied lenght of discount factors is 60 years.
In our bootstrapped curve we do not have so long nodes.
So when we implement the calibration method we get an exception due to the longer
maturity of the underlying instruments with respect to the term structure.
We would like QuantLib to use the extrapolation method to compute these discount factors.
But it seems to us that it is possible to set this optionality only within the inner functions (ex: discountFactor, forward...) and not to an higher level 8for example in the constructor).

- Am I right?
- Did you find the same problem?
- Do you know how to solve this issue?
- Do we need to set manually in QuantLib files the extrapolation at true as default?
- Do you suggest to create another term structure with this optionality in the constructor?

Many thanks in advance,
Enrico

DISCLAIMER: Privileged/Confidential Information may be contained in this message and in any of its attachments (the "message"). If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply e-mail. The contents of this message shall be understood as neither given nor endorsed by Banca Profilo S.p.A., nor Profilo SGR S.p.A., nor Profilo Asset Management SGR S.p.A., nor Profilo Academy S.p.A.. Banca Profilo S.p.A., Profilo SGR S.p.A., Profilo Asset Management SGR S.p.A., Profilo Academy S.p.A. do not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

Il presente messaggio e/o i suoi allegati (di seguito il "messaggio") possono contenere informazioni privilegiate e/o confidenziali. Se non siete i destinatari indicati nel messaggio (o persona incaricata di inoltrare il messaggio al/i destinatario/i), non potete copiare o inoltrare il messaggio ad altri e siete invitati a distruggerlo dandone informazione al mittente a mezzo e-mail. Il contenuto del presente messaggio non deve essere considerato come trasmesso o autorizzato nè da Banca Profilo S.p.A., nè da Profilo SGR S.p.A., nè da Profilo Asset Management SGR S.p.A., nè da Profilo Academy S.p.A.. Nè Banca Profilo S.p.A., nè Profilo SGR S.p.A., nè Profilo Asset Management SGR S.p.A., nè Profilo Academy S.p.A. si assumono alcuna responsabilità per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail e per le eventuali conseguenze.

[Luigi Ballabio-2]

Hi Enrico,

On 2004.04.13 13:05, Michelotti Enrico wrote:
> We have a problem in setting the extrapolation method
> in the term structure class (and derived classes) in case
> we use it to calibrate some models.
> It seems to us that it is possible to set this optionality only
> within the inner functions (ex: discountFactor, forward...) and not  
> to an higher level (for example in the constructor).
>
> - Am I right?

Yes, you are.

> - Did you find the same problem?

Yes, in several classes (volatility term structures, interpolations...)  
But I didn't find the time to code a general solution yet.

> - Do you know how to solve this issue?

We should add a couple of enable/disableExtrapolation() methods to  
those classes, setting a corresponding data member. Then, lower-level  
methods would check that data member besides the local argument.
Also, it would probably be more convenient to encapsulate this in a  
basic class and have TermStructure and such inherit from the latter.

> - Do we need to set manually in QuantLib files the extrapolation at
> true as default?

Yes, I'm afraid this is the simplest solution right now.

> - Do you suggest to create another term structure with this
> optionality in the constructor?

No, I'd rather solve this in a more general way. May you file this as a  
feature request on the QuantLib site? (Or if you code it, you can  
submit it as a patch :)

Later,
        Luigi