blackvariancecurve question - used by the LMM code...

[Toyin Akin]

Hi,

On line #54 of the blackvariancecurve.cpp file, you have a condition that prevents the variances from decreasing.

Can you tell me what the justification for this is?

The reason I am asking is this is that I have a set of caplet data, which looks reasonable (I hope), but fails the test. The data is presented below, the first column is the time (in years), the third column is the caplet volatilities and finally the second column ( sorry about the order of the columns!!) is the result of the formula used within the blackvariancecurve class ( variance = vol*vol*time ).

As you can see, I believe that the caplet vols are reasonable, but at the 3.75 / 4 year marks, the variance data starts to decrease and thus the class throws an exception.

I noticed that within the libormarketmodelprocess.cpp example file, you have an example of passing in caplet vols, where the caplet vol data increases and decreases within the array makeCapVolCurve() function.

Any thoughts...

Toy out.

1.25    0.05        0.2
1.5      0.06615   0.21
1.75    0.0847    0.22
2        0.1058    0.23
2.25    0.1296   0.24
2.5      0.15625  0.25
2.75    0.1859    0.26
3        0.2187    0.27
3.25   0.2548     0.28
3.5     0.29435   0.29
3.75   0.294       0.28
4        0.2916      0.27
4.25   0.2873     0.26
4.5     0.28125    0.25
4.75   0.2736      0.24
5       0.2645     0.23
5.25   0.2541     0.22
5.5     0.24255   0.21
5.75   0.23        0.2
6        0.24       0.2

 

 

[Ferdinando M. Ametrano-3]

> On line #54 of the blackvariancecurve.cpp file, you have a condition that
> prevents the variances from decreasing.
> Can you tell me what the justification for this is?

for a single factor (a stock, or a *single* rate) the variance must be
an increasing function of time. It is easy to understand it if you
think about variance as the integral of a positive quantity: the
square (instantaneous) volatility:
T=t1+t2 (times)
V=v1+v2 (variances)
SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)

> The reason I am asking is this is that I have a set of caplet data, which
> looks reasonable (I hope), but fails the test.
each caplet vol is the vol of a different rate, that is the vol of a
different factor. When it comes to different factors there is no
constraint as V=v1+v2, since v1 refers to a forward rate expiring at
time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
their sum V is a completely undefined concept.

When (different) caplet variance is an increasing function of time it
can be demonstrated that the implied future dynamic of the caplet
variance is time-homogeneous (see Modern Pricing of Interest Rate
Derivatives, by Riccardo Rebonato): as a matter of fact this is not
the case in many markets in the last years

> Any thoughts...
blackvariancecurve can be only used for a single underlying, not for
caplets which are multiple different underlyings

ciao -- Nando

[Toyin Akin]

Hi Nando,

Thanks for the quick reply.

Question, would you consider the rates constructed within the LiborForwardModelProcess class as multiple different underlyings? (Different forward rates even though they have the same period lengths.)

If so, within the LMM implementation, the LiborForwardModelProcess class will construct N factors (or rates). However this class has a setCovarParam() method that takes an instance of an CapletVarianceCurve object. This object uses an instance of a blackvariancecurve class.

If this is the case and the first question is true, then there can be times when this class will fail to construct itself as in my case.

Best Regards,

Toyin Akin.

 

---

From:  "Ferdinando Ametrano" <[hidden email]>
To:  "Toyin Akin" <[hidden email]>
CC:  [hidden email], [hidden email]
Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the LMM code...
Date:  Tue, 7 Mar 2006 19:18:26 +0100

> > On line #54 of the blackvariancecurve.cpp file, you have a condition that
> > prevents the variances from decreasing.
> > Can you tell me what the justification for this is?
>
>for a single factor (a stock, or a *single* rate) the variance must be
>an increasing function of time. It is easy to understand it if you
>think about variance as the integral of a positive quantity: the
>square (instantaneous) volatility:
>T=t1+t2 (times)
>V=v1+v2 (variances)
>SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
>
> > The reason I am asking is this is that I have a set of caplet data, which
> > looks reasonable (I hope), but fails the test.
>each caplet vol is the vol of a different rate, that is the vol of a
>different factor. When it comes to different factors there is no
>constraint as V=v1+v2, since v1 refers to a forward rate expiring at
>time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
>their sum V is a completely undefined concept.
>
>When (different) caplet variance is an increasing function of time it
>can be demonstrated that the implied future dynamic of the caplet
>variance is time-homogeneous (see Modern Pricing of Interest Rate
>Derivatives, by Riccardo Rebonato): as a matter of fact this is not
>the case in many markets in the last years
>
> > Any thoughts...
>blackvariancecurve can be only used for a single underlying, not for
>caplets which are multiple different underlyings
>
>ciao -- Nando
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Klaus Spanderen]

Hi

> blackvariancecurve can be only used for a single underlying, not for
> caplets which are multiple different underlyings

Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
before. I found the class useful to save some lines of code without looking
too much into the details. Toyin you are right, this constraint can cause the
constructor to fail.

I would suggest that we either remove the constraint or I'll doublicate the
functionalilty needed in CapletVarianceCurve. Nando, your advice?

cheers
 Klaus

On Tuesday 07 March 2006 11:01, Toyin Akin wrote:

> Hi Nando,
>
>
> Thanks for the quick reply.
>
>
> Question, would you consider the rates constructed within the
> LiborForwardModelProcess class as multiple different underlyings?
> (Different forward rates even though they have the same period lengths.)
>
>
> If so, within the LMM implementation, the LiborForwardModelProcess class
> will construct N factors (or rates). However this class has a
> setCovarParam() method that takes an instance of an CapletVarianceCurve
> object. This object uses an instance of a blackvariancecurve class.
>
>
> If this is the case and the first question is true, then there can be times
> when this class will fail to construct itself as in my case.
>
>
> Best Regards,
>
>
> Toyin Akin.
>
>
>  
>
>
>
> From:  "Ferdinando Ametrano" <[hidden email]>
> To:  "Toyin Akin" <[hidden email]>
> CC:  [hidden email], [hidden email]
> Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the
> LMM code... Date:  Tue, 7 Mar 2006 19:18:26 +0100
>
> > > On line #54 of the blackvariancecurve.cpp file, you have a condition
> > > that prevents the variances from decreasing.
> > > Can you tell me what the justification for this is?
> >
> >for a single factor (a stock, or a *single* rate) the variance must be
> >an increasing function of time. It is easy to understand it if you
> >think about variance as the integral of a positive quantity: the
> >square (instantaneous) volatility:
> >T=t1+t2 (times)
> >V=v1+v2 (variances)
> >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
> >
> > > The reason I am asking is this is that I have a set of caplet data,
> > > which looks reasonable (I hope), but fails the test.
> >
> >each caplet vol is the vol of a different rate, that is the vol of a
> >different factor. When it comes to different factors there is no
> >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
> >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
> >their sum V is a completely undefined concept.
> >
> >When (different) caplet variance is an increasing function of time it
> >can be demonstrated that the implied future dynamic of the caplet
> >variance is time-homogeneous (see Modern Pricing of Interest Rate
> >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
> >the case in many markets in the last years
> >
> > > Any thoughts...
> >
> >blackvariancecurve can be only used for a single underlying, not for
> >caplets which are multiple different underlyings
> >
> >ciao -- Nando
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory!
> > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> > _______________________________________________
> >Quantlib-users mailing list
> >[hidden email]
> >https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>  ------------------------------------------------------- This SF.Net email
> is sponsored by xPML, a groundbreaking scripting language that extends
> applications into web and mobile media. Attend the live webcast and join
> the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________ Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

--
_______________________________________________________
Klaus Spanderen
Hubertustal 13f
48734 Reken (Germany)
Email: [hidden email]
(remove NOSPAM from the address)
http://www.spanderen.de

[Toyin Akin]

Thanks Klaus,

I'll wait for Nando's response on this, one further question for you, the constructor of the LiborForwardModelProcess class takes a length and an index object. This suggests to me that diagonal forward rates will be constructed, the first one starting from the YieldCurve's reference date.

Is it possible to add a further constructor that may take a cashflow array (instead of constructing this internally). This array may represent the floating rates of a forward swap (say 5Y into 5Y).

Right now, the class can only handle, cashflows from the spot date (reference date).

Will it be the case that this will be the only change needed?

Or does the whole LMM implementation assume that the cashflow array starts from spot?

Finally, good work on this Klaus, I do like your implementation, very neat.

Best Regards,

Toyin Akin.

---

From:  Klaus Spanderen <[hidden email]>
To:  [hidden email], [hidden email]
CC:  [hidden email]
Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the LMM code...
Date:  Tue, 7 Mar 2006 21:28:46 -0800

>Hi
>
> > blackvariancecurve can be only used for a single underlying, not for
> > caplets which are multiple different underlyings
>
>Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
>before. I found the class useful to save some lines of code without looking
>too much into the details. Toyin you are right, this constraint can cause the
>constructor to fail.
>
>I would suggest that we either remove the constraint or I'll doublicate the
>functionalilty needed in CapletVarianceCurve. Nando, your advice?
>
>cheers
>  Klaus
>
>On Tuesday 07 March 2006 11:01, Toyin Akin wrote:
> > Hi Nando,
> >
> >
> > Thanks for the quick reply.
> >
> >
> > Question, would you consider the rates constructed within the
> > LiborForwardModelProcess class as multiple different underlyings?
> > (Different forward rates even though they have the same period lengths.)
> >
> >
> > If so, within the LMM implementation, the LiborForwardModelProcess class
> > will construct N factors (or rates). However this class has a
> > setCovarParam() method that takes an instance of an CapletVarianceCurve
> > object. This object uses an instance of a blackvariancecurve class.
> >
> >
> > If this is the case and the first question is true, then there can be times
> > when this class will fail to construct itself as in my case.
> >
> >
> > Best Regards,
> >
> >
> > Toyin Akin.
> >
> >
> >  
> >
> >
> >
> > From:  "Ferdinando Ametrano" <[hidden email]>
> > To:  "Toyin Akin" <[hidden email]>
> > CC:  [hidden email], [hidden email]
> > Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the
> > LMM code... Date:  Tue, 7 Mar 2006 19:18:26 +0100
> >
> > > > On line #54 of the blackvariancecurve.cpp file, you have a condition
> > > > that prevents the variances from decreasing.
> > > > Can you tell me what the justification for this is?
> > >
> > >for a single factor (a stock, or a *single* rate) the variance must be
> > >an increasing function of time. It is easy to understand it if you
> > >think about variance as the integral of a positive quantity: the
> > >square (instantaneous) volatility:
> > >T=t1+t2 (times)
> > >V=v1+v2 (variances)
> > >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
> > >
> > > > The reason I am asking is this is that I have a set of caplet data,
> > > > which looks reasonable (I hope), but fails the test.
> > >
> > >each caplet vol is the vol of a different rate, that is the vol of a
> > >different factor. When it comes to different factors there is no
> > >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
> > >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
> > >their sum V is a completely undefined concept.
> > >
> > >When (different) caplet variance is an increasing function of time it
> > >can be demonstrated that the implied future dynamic of the caplet
> > >variance is time-homogeneous (see Modern Pricing of Interest Rate
> > >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
> > >the case in many markets in the last years
> > >
> > > > Any thoughts...
> > >
> > >blackvariancecurve can be only used for a single underlying, not for
> > >caplets which are multiple different underlyings
> > >
> > >ciao -- Nando
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language that extends applications into web and mobile media. Attend the
> > > live webcast and join the prime developer group breaking into this new
> > > coding territory!
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> > > _______________________________________________
> > >Quantlib-users mailing list
> > >[hidden email]
> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
> >  ------------------------------------------------------- This SF.Net email
> > is sponsored by xPML, a groundbreaking scripting language that extends
> > applications into web and mobile media. Attend the live webcast and join
> > the prime developer group breaking into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________ Quantlib-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>--
>_______________________________________________________
>Klaus Spanderen
>Hubertustal 13f
>48734 Reken (Germany)
>Email: [hidden email]
>(remove NOSPAM from the address)
>http://www.spanderen.de

[Toyin Akin]

Hi again,

Actually Klaus, it looks like the LfmHullWhiteParameterization class assumes
that the first diagonal forward starts from spot as N-1 caplet vols are
required.

Thus from the current implementation, if one wanted to price a 5Y into 5Y
ratchet cap, one would have to simulate the Libors from Spot into 10Y, but
discard the first 5 years!!!

Best Regards,
Toyin Akin.

From: "Toyin Akin" <[hidden email]>
To: [hidden email], [hidden email]
CC: [hidden email]
Subject: Re: [Quantlib-users] blackvariancecurve question - used by the LMM
code...
Date: Wed, 08 Mar 2006 02:20:30 +0000


Thanks Klaus,
I'll wait for Nando's response on this, one further question for you, the
constructor of the LiborForwardModelProcess class takes a length and an
index object. This suggests to me that diagonal forward rates will be
constructed, the first one starting from the YieldCurve's reference date.
Is it possible to add a further constructor that may take a cashflow array
(instead of constructing this internally). This array may represent the
floating rates of a forward swap (say 5Y into 5Y).
Right now, the class can only handle, cashflows from the spot date
(reference date).
Will it be the case that this will be the only change needed?
Or does the whole LMM implementation assume that the cashflow array starts
from spot?
Finally, good work on this Klaus, I do like your implementation, very neat.
Best Regards,
Toyin Akin.




From:  Klaus Spanderen <[hidden email]>
To:  [hidden email], [hidden email]
CC:  [hidden email]
Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the LMM
code...
Date:  Tue, 7 Mar 2006 21:28:46 -0800

>Hi
>
> > blackvariancecurve can be only used for a single underlying, not for
> > caplets which are multiple different underlyings
>
>Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
>before. I found the class useful to save some lines of code without looking
>too much into the details. Toyin you are right, this constraint can cause
>the
>constructor to fail.
>
>I would suggest that we either remove the constraint or I'll doublicate the
>functionalilty needed in CapletVarianceCurve. Nando, your advice?
>
>cheers
>  Klaus
>
>On Tuesday 07 March 2006 11:01, Toyin Akin wrote:
> > Hi Nando,
> >
> >
> > Thanks for the quick reply.
> >
> >
> > Question, would you consider the rates constructed within the
> > LiborForwardModelProcess class as multiple different underlyings?
> > (Different forward rates even though they have the same period lengths.)
> >
> >
> > If so, within the LMM implementation, the LiborForwardModelProcess class
> > will construct N factors (or rates). However this class has a
> > setCovarParam() method that takes an instance of an CapletVarianceCurve
> > object. This object uses an instance of a blackvariancecurve class.
> >
> >
> > If this is the case and the first question is true, then there can be
>times
> > when this class will fail to construct itself as in my case.
> >
> >
> > Best Regards,
> >
> >
> > Toyin Akin.
> >
> >
> > Â >
> >
> >
> > From:Â Â "Ferdinando Ametrano" <[hidden email]>
> > To:Â Â "Toyin Akin" <[hidden email]>
> > CC:Â Â [hidden email], [hidden email]
> > Subject:Â Â Re: [Quantlib-users] blackvariancecurve question - used by
>the
> > LMM code... Date:Â Â Tue, 7 Mar 2006 19:18:26 +0100
> >
> > > > On line #54 of the blackvariancecurve.cpp file, you have a condition
> > > > that prevents the variances from decreasing.
> > > > Can you tell me what the justification for this is?
> > >
> > >for a single factor (a stock, or a *single* rate) the variance must be
> > >an increasing function of time. It is easy to understand it if you
> > >think about variance as the integral of a positive quantity: the
> > >square (instantaneous) volatility:
> > >T=t1+t2 (times)
> > >V=v1+v2 (variances)
> > >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
> > >
> > > > The reason I am asking is this is that I have a set of caplet data,
> > > > which looks reasonable (I hope), but fails the test.
> > >
> > >each caplet vol is the vol of a different rate, that is the vol of a
> > >different factor. When it comes to different factors there is no
> > >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
> > >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
> > >their sum V is a completely undefined concept.
> > >
> > >When (different) caplet variance is an increasing function of time it
> > >can be demonstrated that the implied future dynamic of the caplet
> > >variance is time-homogeneous (see Modern Pricing of Interest Rate
> > >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
> > >the case in many markets in the last years
> > >
> > > > Any thoughts...
> > >
> > >blackvariancecurve can be only used for a single underlying, not for
> > >caplets which are multiple different underlyings
> > >
> > >ciao -- Nando
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language that extends applications into web and mobile media. Attend
>the
> > > live webcast and join the prime developer group breaking into this new
> > > coding territory!
> > > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> > > _______________________________________________
> > >Quantlib-users mailing list
> > >[hidden email]
> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
> >  ------------------------------------------------------- This SF.Net
>email
> > is sponsored by xPML, a groundbreaking scripting language that extends
> > applications into web and mobile media. Attend the live webcast and join
> > the prime developer group breaking into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________ Quantlib-users mailing
>list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>--
>_______________________________________________________
>Klaus Spanderen
>Hubertustal 13f
>48734 Reken (Germany)
>Email: [hidden email]
>(remove NOSPAM from the address)
>http://www.spanderen.de

------------------------------------------------------- This SF.Net email is
sponsored by xPML, a groundbreaking scripting language that extends
applications into web and mobile media. Attend the live webcast and join the
prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
_______________________________________________ Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Toyin Akin]

Hi Klaus,

This may be a silly question so please forgive me but why is the first
forward rate (constructed within the LiborForwardModelProcess class)
actually there?

Why not :

        return FloatingRateCouponVector(
                   Schedule(index_->calendar(),
                            refDate + Period(index_->tenor().length(),
                            refDate + Period(index_->tenor().length()*size_,
                                             index_->tenor().units()),
                            index_->frequency(),
                            index_->businessDayConvention()
                            ),
                   index_->businessDayConvention(),
                   std::vector<Real>(1, amount),
                   index_,
                   index_->settlementDays(),
                   std::vector<Spread>(),
                   index_->dayCounter()
                   );

instead of

        return FloatingRateCouponVector(
                   Schedule(index_->calendar(),
                            refDate,
                            refDate + Period(index_->tenor().length()*size_,
                                             index_->tenor().units()),
                            index_->frequency(),
                            index_->businessDayConvention()
                            ),
                   index_->businessDayConvention(),
                   std::vector<Real>(1, amount),
                   index_,
                   index_->settlementDays(),
                   std::vector<Spread>(),
                   index_->dayCounter()
                   );

Given the current implementation, within a MonteCarlo simulation, the first
forward always generates the same rate and within any caplet type pricing it
will always be the instrinsic value as the exercise date is actually Todays
date.

If this forward rate is removed and the other classes that assume this
modified, then the LMM infrastructure can price cap type products starting
in the future (assuming a cashflow constructor also).

Thoughts?

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email], [hidden email]
>CC: [hidden email]
>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the LMM
>code...
>Date: Wed, 08 Mar 2006 03:39:37 +0000
>
>
>Hi again,
>
>Actually Klaus, it looks like the LfmHullWhiteParameterization class
>assumes that the first diagonal forward starts from spot as N-1 caplet vols
>are required.
>
>Thus from the current implementation, if one wanted to price a 5Y into 5Y
>ratchet cap, one would have to simulate the Libors from Spot into 10Y, but
>discard the first 5 years!!!
>
>Best Regards,
>Toyin Akin.
>
>From: "Toyin Akin" <[hidden email]>
>To: [hidden email], [hidden email]
>CC: [hidden email]
>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the LMM
>code...
>Date: Wed, 08 Mar 2006 02:20:30 +0000
>
>
>Thanks Klaus,
>I'll wait for Nando's response on this, one further question for you, the
>constructor of the LiborForwardModelProcess class takes a length and an
>index object. This suggests to me that diagonal forward rates will be
>constructed, the first one starting from the YieldCurve's reference date.
>Is it possible to add a further constructor that may take a cashflow array
>(instead of constructing this internally). This array may represent the
>floating rates of a forward swap (say 5Y into 5Y).
>Right now, the class can only handle, cashflows from the spot date
>(reference date).
>Will it be the case that this will be the only change needed?
>Or does the whole LMM implementation assume that the cashflow array starts
>from spot?
>Finally, good work on this Klaus, I do like your implementation, very neat.
>Best Regards,
>Toyin Akin.
>
>
>
>
>From:  Klaus Spanderen <[hidden email]>
>To:  [hidden email], [hidden email]
>CC:  [hidden email]
>Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the
>LMM code...
>Date:  Tue, 7 Mar 2006 21:28:46 -0800
>>Hi
>>
>> > blackvariancecurve can be only used for a single underlying, not for
>> > caplets which are multiple different underlyings
>>
>>Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
>>before. I found the class useful to save some lines of code without
>>looking
>>too much into the details. Toyin you are right, this constraint can cause
>>the
>>constructor to fail.
>>
>>I would suggest that we either remove the constraint or I'll doublicate
>>the
>>functionalilty needed in CapletVarianceCurve. Nando, your advice?
>>
>>cheers
>>  Klaus
>>
>>On Tuesday 07 March 2006 11:01, Toyin Akin wrote:
>> > Hi Nando,
>> >
>> >
>> > Thanks for the quick reply.
>> >
>> >
>> > Question, would you consider the rates constructed within the
>> > LiborForwardModelProcess class as multiple different underlyings?
>> > (Different forward rates even though they have the same period
>>lengths.)
>> >
>> >
>> > If so, within the LMM implementation, the LiborForwardModelProcess
>>class
>> > will construct N factors (or rates). However this class has a
>> > setCovarParam() method that takes an instance of an CapletVarianceCurve
>> > object. This object uses an instance of a blackvariancecurve class.
>> >
>> >
>> > If this is the case and the first question is true, then there can be
>>times
>> > when this class will fail to construct itself as in my case.
>> >
>> >
>> > Best Regards,
>> >
>> >
>> > Toyin Akin.
>> >
>> >
>> > Â >
>> >
>> >
>> > From:Â Â "Ferdinando Ametrano" <[hidden email]>
>> > To:Â Â "Toyin Akin" <[hidden email]>
>> > CC:Â Â [hidden email], [hidden email]
>> > Subject:Â Â Re: [Quantlib-users] blackvariancecurve question - used by
>>the
>> > LMM code... Date:Â Â Tue, 7 Mar 2006 19:18:26 +0100
>> >
>> > > > On line #54 of the blackvariancecurve.cpp file, you have a
>>condition
>> > > > that prevents the variances from decreasing.
>> > > > Can you tell me what the justification for this is?
>> > >
>> > >for a single factor (a stock, or a *single* rate) the variance must be
>> > >an increasing function of time. It is easy to understand it if you
>> > >think about variance as the integral of a positive quantity: the
>> > >square (instantaneous) volatility:
>> > >T=t1+t2 (times)
>> > >V=v1+v2 (variances)
>> > >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
>> > >
>> > > > The reason I am asking is this is that I have a set of caplet data,
>> > > > which looks reasonable (I hope), but fails the test.
>> > >
>> > >each caplet vol is the vol of a different rate, that is the vol of a
>> > >different factor. When it comes to different factors there is no
>> > >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
>> > >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
>> > >their sum V is a completely undefined concept.
>> > >
>> > >When (different) caplet variance is an increasing function of time it
>> > >can be demonstrated that the implied future dynamic of the caplet
>> > >variance is time-homogeneous (see Modern Pricing of Interest Rate
>> > >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
>> > >the case in many markets in the last years
>> > >
>> > > > Any thoughts...
>> > >
>> > >blackvariancecurve can be only used for a single underlying, not for
>> > >caplets which are multiple different underlyings
>> > >
>> > >ciao -- Nando
>> > >
>> > >
>> > >-------------------------------------------------------
>> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> > > language that extends applications into web and mobile media. Attend
>>the
>> > > live webcast and join the prime developer group breaking into this
>>new
>> > > coding territory!
>> > > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
>> > > _______________________________________________
>> > >Quantlib-users mailing list
>> > >[hidden email]
>> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >
>> >  ------------------------------------------------------- This SF.Net
>>email
>> > is sponsored by xPML, a groundbreaking scripting language that extends
>> > applications into web and mobile media. Attend the live webcast and
>>join
>> > the prime developer group breaking into this new coding territory!
>> >
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> > _______________________________________________ Quantlib-users mailing
>>list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>>--
>>_______________________________________________________
>>Klaus Spanderen
>>Hubertustal 13f
>>48734 Reken (Germany)
>>Email: [hidden email]
>>(remove NOSPAM from the address)
>>http://www.spanderen.de
>
>------------------------------------------------------- This SF.Net email
>is sponsored by xPML, a groundbreaking scripting language that extends
>applications into web and mobile media. Attend the live webcast and join
>the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
>_______________________________________________ Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live
>webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Toyin Akin]

Hi,

Thinking about it a bit more, I guess it depends on whether you wish to have
the intrinsic value for the first cap as part of your NPV, however I believe
that this can be computed outside the Monte Carlo logic (within the LMM
examples), because the forward rate used is just that implied from the
YieldCurve.

Best Regards,
Toyin Akin.

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email], [hidden email]
>CC: [hidden email]
>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the LMM
>code...
>Date: Wed, 08 Mar 2006 04:14:53 +0000
>
>
>Hi Klaus,
>
>This may be a silly question so please forgive me but why is the first
>forward rate (constructed within the LiborForwardModelProcess class)
>actually there?
>
>Why not :
>
>        return FloatingRateCouponVector(
>                   Schedule(index_->calendar(),
>                            refDate + Period(index_->tenor().length(),
>                            refDate +
>Period(index_->tenor().length()*size_,
>                                             index_->tenor().units()),
>                            index_->frequency(),
>                            index_->businessDayConvention()
>                            ),
>                   index_->businessDayConvention(),
>                   std::vector<Real>(1, amount),
>                   index_,
>                   index_->settlementDays(),
>                   std::vector<Spread>(),
>                   index_->dayCounter()
>                   );
>
>instead of
>
>        return FloatingRateCouponVector(
>                   Schedule(index_->calendar(),
>                            refDate,
>                            refDate +
>Period(index_->tenor().length()*size_,
>                                             index_->tenor().units()),
>                            index_->frequency(),
>                            index_->businessDayConvention()
>                            ),
>                   index_->businessDayConvention(),
>                   std::vector<Real>(1, amount),
>                   index_,
>                   index_->settlementDays(),
>                   std::vector<Spread>(),
>                   index_->dayCounter()
>                   );
>
>Given the current implementation, within a MonteCarlo simulation, the first
>forward always generates the same rate and within any caplet type pricing
>it will always be the instrinsic value as the exercise date is actually
>Todays date.
>
>If this forward rate is removed and the other classes that assume this
>modified, then the LMM infrastructure can price cap type products starting
>in the future (assuming a cashflow constructor also).
>
>Thoughts?
>
>>From: "Toyin Akin" <[hidden email]>
>>To: [hidden email], [hidden email]
>>CC: [hidden email]
>>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the
>>LMM code...
>>Date: Wed, 08 Mar 2006 03:39:37 +0000
>>
>>
>>Hi again,
>>
>>Actually Klaus, it looks like the LfmHullWhiteParameterization class
>>assumes that the first diagonal forward starts from spot as N-1 caplet
>>vols are required.
>>
>>Thus from the current implementation, if one wanted to price a 5Y into 5Y
>>ratchet cap, one would have to simulate the Libors from Spot into 10Y, but
>>discard the first 5 years!!!
>>
>>Best Regards,
>>Toyin Akin.
>>
>>From: "Toyin Akin" <[hidden email]>
>>To: [hidden email], [hidden email]
>>CC: [hidden email]
>>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the
>>LMM code...
>>Date: Wed, 08 Mar 2006 02:20:30 +0000
>>
>>
>>Thanks Klaus,
>>I'll wait for Nando's response on this, one further question for you, the
>>constructor of the LiborForwardModelProcess class takes a length and an
>>index object. This suggests to me that diagonal forward rates will be
>>constructed, the first one starting from the YieldCurve's reference date.
>>Is it possible to add a further constructor that may take a cashflow array
>>(instead of constructing this internally). This array may represent the
>>floating rates of a forward swap (say 5Y into 5Y).
>>Right now, the class can only handle, cashflows from the spot date
>>(reference date).
>>Will it be the case that this will be the only change needed?
>>Or does the whole LMM implementation assume that the cashflow array starts
>>from spot?
>>Finally, good work on this Klaus, I do like your implementation, very
>>neat.
>>Best Regards,
>>Toyin Akin.
>>
>>
>>
>>
>>From:  Klaus Spanderen <[hidden email]>
>>To:  [hidden email], [hidden email]
>>CC:  [hidden email]
>>Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the
>>LMM code...
>>Date:  Tue, 7 Mar 2006 21:28:46 -0800
>>>Hi
>>>
>>> > blackvariancecurve can be only used for a single underlying, not for
>>> > caplets which are multiple different underlyings
>>>
>>>Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
>>>before. I found the class useful to save some lines of code without
>>>looking
>>>too much into the details. Toyin you are right, this constraint can cause
>>>the
>>>constructor to fail.
>>>
>>>I would suggest that we either remove the constraint or I'll doublicate
>>>the
>>>functionalilty needed in CapletVarianceCurve. Nando, your advice?
>>>
>>>cheers
>>>  Klaus
>>>
>>>On Tuesday 07 March 2006 11:01, Toyin Akin wrote:
>>> > Hi Nando,
>>> >
>>> >
>>> > Thanks for the quick reply.
>>> >
>>> >
>>> > Question, would you consider the rates constructed within the
>>> > LiborForwardModelProcess class as multiple different underlyings?
>>> > (Different forward rates even though they have the same period
>>>lengths.)
>>> >
>>> >
>>> > If so, within the LMM implementation, the LiborForwardModelProcess
>>>class
>>> > will construct N factors (or rates). However this class has a
>>> > setCovarParam() method that takes an instance of an
>>>CapletVarianceCurve
>>> > object. This object uses an instance of a blackvariancecurve class.
>>> >
>>> >
>>> > If this is the case and the first question is true, then there can be
>>>times
>>> > when this class will fail to construct itself as in my case.
>>> >
>>> >
>>> > Best Regards,
>>> >
>>> >
>>> > Toyin Akin.
>>> >
>>> >
>>> > Â >
>>> >
>>> >
>>> > From:Â Â "Ferdinando Ametrano" <[hidden email]>
>>> > To:Â Â "Toyin Akin" <[hidden email]>
>>> > CC:Â Â [hidden email], [hidden email]
>>> > Subject:Â Â Re: [Quantlib-users] blackvariancecurve question - used by
>>>the
>>> > LMM code... Date:Â Â Tue, 7 Mar 2006 19:18:26 +0100
>>> >
>>> > > > On line #54 of the blackvariancecurve.cpp file, you have a
>>>condition
>>> > > > that prevents the variances from decreasing.
>>> > > > Can you tell me what the justification for this is?
>>> > >
>>> > >for a single factor (a stock, or a *single* rate) the variance must
>>>be
>>> > >an increasing function of time. It is easy to understand it if you
>>> > >think about variance as the integral of a positive quantity: the
>>> > >square (instantaneous) volatility:
>>> > >T=t1+t2 (times)
>>> > >V=v1+v2 (variances)
>>> > >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
>>> > >
>>> > > > The reason I am asking is this is that I have a set of caplet
>>>data,
>>> > > > which looks reasonable (I hope), but fails the test.
>>> > >
>>> > >each caplet vol is the vol of a different rate, that is the vol of a
>>> > >different factor. When it comes to different factors there is no
>>> > >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
>>> > >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
>>> > >their sum V is a completely undefined concept.
>>> > >
>>> > >When (different) caplet variance is an increasing function of time it
>>> > >can be demonstrated that the implied future dynamic of the caplet
>>> > >variance is time-homogeneous (see Modern Pricing of Interest Rate
>>> > >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
>>> > >the case in many markets in the last years
>>> > >
>>> > > > Any thoughts...
>>> > >
>>> > >blackvariancecurve can be only used for a single underlying, not for
>>> > >caplets which are multiple different underlyings
>>> > >
>>> > >ciao -- Nando
>>> > >
>>> > >
>>> > >-------------------------------------------------------
>>> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>> > > language that extends applications into web and mobile media. Attend
>>>the
>>> > > live webcast and join the prime developer group breaking into this
>>>new
>>> > > coding territory!
>>> > > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
>>> > > _______________________________________________
>>> > >Quantlib-users mailing list
>>> > >[hidden email]
>>> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>> >
>>> >  ------------------------------------------------------- This SF.Net
>>>email
>>> > is sponsored by xPML, a groundbreaking scripting language that extends
>>> > applications into web and mobile media. Attend the live webcast and
>>>join
>>> > the prime developer group breaking into this new coding territory!
>>> >
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>> > _______________________________________________ Quantlib-users mailing
>>>list
>>> > [hidden email]
>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>>--
>>>_______________________________________________________
>>>Klaus Spanderen
>>>Hubertustal 13f
>>>48734 Reken (Germany)
>>>Email: [hidden email]
>>>(remove NOSPAM from the address)
>>>http://www.spanderen.de
>>
>>------------------------------------------------------- This SF.Net email
>>is sponsored by xPML, a groundbreaking scripting language that extends
>>applications into web and mobile media. Attend the live webcast and join
>>the prime developer group breaking into this new coding territory!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
>>_______________________________________________ Quantlib-users mailing
>>list [hidden email]
>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>language
>>that extends applications into web and mobile media. Attend the live
>>webcast
>>and join the prime developer group breaking into this new coding
>>territory!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>_______________________________________________
>>Quantlib-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live
>webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Toyin Akin]

Hi,

Pest again...

Or you could have the constructor take a boolean as to whether or not to
discard the first forward (if it detects that the fixing date is the same as
the referenceDate).

This boolean can then be filtered down to all supporting classes that
require this information.

Thoughts...?

Toy out.

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email], [hidden email]
>CC: [hidden email]
>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the LMM
>code...
>Date: Wed, 08 Mar 2006 04:34:23 +0000
>
>
>Hi,
>
>Thinking about it a bit more, I guess it depends on whether you wish to
>have the intrinsic value for the first cap as part of your NPV, however I
>believe that this can be computed outside the Monte Carlo logic (within the
>LMM examples), because the forward rate used is just that implied from the
>YieldCurve.
>
>Best Regards,
>Toyin Akin.
>
>>From: "Toyin Akin" <[hidden email]>
>>To: [hidden email], [hidden email]
>>CC: [hidden email]
>>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the
>>LMM code...
>>Date: Wed, 08 Mar 2006 04:14:53 +0000
>>
>>
>>Hi Klaus,
>>
>>This may be a silly question so please forgive me but why is the first
>>forward rate (constructed within the LiborForwardModelProcess class)
>>actually there?
>>
>>Why not :
>>
>>        return FloatingRateCouponVector(
>>                   Schedule(index_->calendar(),
>>                            refDate + Period(index_->tenor().length(),
>>                            refDate +
>>Period(index_->tenor().length()*size_,
>>                                             index_->tenor().units()),
>>                            index_->frequency(),
>>                            index_->businessDayConvention()
>>                            ),
>>                   index_->businessDayConvention(),
>>                   std::vector<Real>(1, amount),
>>                   index_,
>>                   index_->settlementDays(),
>>                   std::vector<Spread>(),
>>                   index_->dayCounter()
>>                   );
>>
>>instead of
>>
>>        return FloatingRateCouponVector(
>>                   Schedule(index_->calendar(),
>>                            refDate,
>>                            refDate +
>>Period(index_->tenor().length()*size_,
>>                                             index_->tenor().units()),
>>                            index_->frequency(),
>>                            index_->businessDayConvention()
>>                            ),
>>                   index_->businessDayConvention(),
>>                   std::vector<Real>(1, amount),
>>                   index_,
>>                   index_->settlementDays(),
>>                   std::vector<Spread>(),
>>                   index_->dayCounter()
>>                   );
>>
>>Given the current implementation, within a MonteCarlo simulation, the
>>first forward always generates the same rate and within any caplet type
>>pricing it will always be the instrinsic value as the exercise date is
>>actually Todays date.
>>
>>If this forward rate is removed and the other classes that assume this
>>modified, then the LMM infrastructure can price cap type products starting
>>in the future (assuming a cashflow constructor also).
>>
>>Thoughts?
>>
>>>From: "Toyin Akin" <[hidden email]>
>>>To: [hidden email], [hidden email]
>>>CC: [hidden email]
>>>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the
>>>LMM code...
>>>Date: Wed, 08 Mar 2006 03:39:37 +0000
>>>
>>>
>>>Hi again,
>>>
>>>Actually Klaus, it looks like the LfmHullWhiteParameterization class
>>>assumes that the first diagonal forward starts from spot as N-1 caplet
>>>vols are required.
>>>
>>>Thus from the current implementation, if one wanted to price a 5Y into 5Y
>>>ratchet cap, one would have to simulate the Libors from Spot into 10Y,
>>>but discard the first 5 years!!!
>>>
>>>Best Regards,
>>>Toyin Akin.
>>>
>>>From: "Toyin Akin" <[hidden email]>
>>>To: [hidden email], [hidden email]
>>>CC: [hidden email]
>>>Subject: Re: [Quantlib-users] blackvariancecurve question - used by the
>>>LMM code...
>>>Date: Wed, 08 Mar 2006 02:20:30 +0000
>>>
>>>
>>>Thanks Klaus,
>>>I'll wait for Nando's response on this, one further question for you, the
>>>constructor of the LiborForwardModelProcess class takes a length and an
>>>index object. This suggests to me that diagonal forward rates will be
>>>constructed, the first one starting from the YieldCurve's reference date.
>>>Is it possible to add a further constructor that may take a cashflow
>>>array (instead of constructing this internally). This array may represent
>>>the floating rates of a forward swap (say 5Y into 5Y).
>>>Right now, the class can only handle, cashflows from the spot date
>>>(reference date).
>>>Will it be the case that this will be the only change needed?
>>>Or does the whole LMM implementation assume that the cashflow array
>>>starts from spot?
>>>Finally, good work on this Klaus, I do like your implementation, very
>>>neat.
>>>Best Regards,
>>>Toyin Akin.
>>>
>>>
>>>
>>>
>>>From:  Klaus Spanderen <[hidden email]>
>>>To:  [hidden email], [hidden email]
>>>CC:  [hidden email]
>>>Subject:  Re: [Quantlib-users] blackvariancecurve question - used by the
>>>LMM code...
>>>Date:  Tue, 7 Mar 2006 21:28:46 -0800
>>>>Hi
>>>>
>>>> > blackvariancecurve can be only used for a single underlying, not for
>>>> > caplets which are multiple different underlyings
>>>>
>>>>Nando, haven't realized the constraint in line 54 of BlackVarianceCurve
>>>>before. I found the class useful to save some lines of code without
>>>>looking
>>>>too much into the details. Toyin you are right, this constraint can
>>>>cause the
>>>>constructor to fail.
>>>>
>>>>I would suggest that we either remove the constraint or I'll doublicate
>>>>the
>>>>functionalilty needed in CapletVarianceCurve. Nando, your advice?
>>>>
>>>>cheers
>>>>  Klaus
>>>>
>>>>On Tuesday 07 March 2006 11:01, Toyin Akin wrote:
>>>> > Hi Nando,
>>>> >
>>>> >
>>>> > Thanks for the quick reply.
>>>> >
>>>> >
>>>> > Question, would you consider the rates constructed within the
>>>> > LiborForwardModelProcess class as multiple different underlyings?
>>>> > (Different forward rates even though they have the same period
>>>>lengths.)
>>>> >
>>>> >
>>>> > If so, within the LMM implementation, the LiborForwardModelProcess
>>>>class
>>>> > will construct N factors (or rates). However this class has a
>>>> > setCovarParam() method that takes an instance of an
>>>>CapletVarianceCurve
>>>> > object. This object uses an instance of a blackvariancecurve class.
>>>> >
>>>> >
>>>> > If this is the case and the first question is true, then there can be
>>>>times
>>>> > when this class will fail to construct itself as in my case.
>>>> >
>>>> >
>>>> > Best Regards,
>>>> >
>>>> >
>>>> > Toyin Akin.
>>>> >
>>>> >
>>>> > Â >
>>>> >
>>>> >
>>>> > From:Â Â "Ferdinando Ametrano" <[hidden email]>
>>>> > To:Â Â "Toyin Akin" <[hidden email]>
>>>> > CC:Â Â [hidden email], [hidden email]
>>>> > Subject:Â Â Re: [Quantlib-users] blackvariancecurve question - used
>>>>by the
>>>> > LMM code... Date:Â Â Tue, 7 Mar 2006 19:18:26 +0100
>>>> >
>>>> > > > On line #54 of the blackvariancecurve.cpp file, you have a
>>>>condition
>>>> > > > that prevents the variances from decreasing.
>>>> > > > Can you tell me what the justification for this is?
>>>> > >
>>>> > >for a single factor (a stock, or a *single* rate) the variance must
>>>>be
>>>> > >an increasing function of time. It is easy to understand it if you
>>>> > >think about variance as the integral of a positive quantity: the
>>>> > >square (instantaneous) volatility:
>>>> > >T=t1+t2 (times)
>>>> > >V=v1+v2 (variances)
>>>> > >SIGMA^2 T = sigma1^2 t1 + sigma2^2 t2 (vols)
>>>> > >
>>>> > > > The reason I am asking is this is that I have a set of caplet
>>>>data,
>>>> > > > which looks reasonable (I hope), but fails the test.
>>>> > >
>>>> > >each caplet vol is the vol of a different rate, that is the vol of a
>>>> > >different factor. When it comes to different factors there is no
>>>> > >constraint as V=v1+v2, since v1 refers to a forward rate expiring at
>>>> > >time t1 and v2 refers to a DIFFERENT forward rate expiring at t2:
>>>> > >their sum V is a completely undefined concept.
>>>> > >
>>>> > >When (different) caplet variance is an increasing function of time
>>>>it
>>>> > >can be demonstrated that the implied future dynamic of the caplet
>>>> > >variance is time-homogeneous (see Modern Pricing of Interest Rate
>>>> > >Derivatives, by Riccardo Rebonato): as a matter of fact this is not
>>>> > >the case in many markets in the last years
>>>> > >
>>>> > > > Any thoughts...
>>>> > >
>>>> > >blackvariancecurve can be only used for a single underlying, not for
>>>> > >caplets which are multiple different underlyings
>>>> > >
>>>> > >ciao -- Nando
>>>> > >
>>>> > >
>>>> > >-------------------------------------------------------
>>>> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> > > language that extends applications into web and mobile media.
>>>>Attend the
>>>> > > live webcast and join the prime developer group breaking into this
>>>>new
>>>> > > coding territory!
>>>> > > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
>>>> > > _______________________________________________
>>>> > >Quantlib-users mailing list
>>>> > >[hidden email]
>>>> > >https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> >
>>>> >  ------------------------------------------------------- This SF.Net
>>>>email
>>>> > is sponsored by xPML, a groundbreaking scripting language that
>>>>extends
>>>> > applications into web and mobile media. Attend the live webcast and
>>>>join
>>>> > the prime developer group breaking into this new coding territory!
>>>> >
>>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> > _______________________________________________ Quantlib-users
>>>>mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>>--
>>>>_______________________________________________________
>>>>Klaus Spanderen
>>>>Hubertustal 13f
>>>>48734 Reken (Germany)
>>>>Email: [hidden email]
>>>>(remove NOSPAM from the address)
>>>>http://www.spanderen.de
>>>
>>>------------------------------------------------------- This SF.Net email
>>>is sponsored by xPML, a groundbreaking scripting language that extends
>>>applications into web and mobile media. Attend the live webcast and join
>>>the prime developer group breaking into this new coding territory!
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
>>>_______________________________________________ Quantlib-users mailing
>>>list [hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>language
>>>that extends applications into web and mobile media. Attend the live
>>>webcast
>>>and join the prime developer group breaking into this new coding
>>>territory!
>>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>_______________________________________________
>>>Quantlib-users mailing list
>>>[hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>language
>>that extends applications into web and mobile media. Attend the live
>>webcast
>>and join the prime developer group breaking into this new coding
>>territory!
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>_______________________________________________
>>Quantlib-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live
>webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

Toyin wrote:
> Question, would you consider the rates constructed within the
> LiborForwardModelProcess class as multiple different underlyings?
> (Different forward rates even though they have the same period lengths.)
I haven't checked the class but they ARE different underlyings.
Strongly correlated, but different underlyings

Klaus wrote:
> I would suggest that we either remove the constraint or I'll doublicate the
> functionalilty needed in CapletVarianceCurve. Nando, your advice?

I would definitely design a dedicated class for caplet variance. I
suggest to digest Rebonato's discussion about it as guideline.

Too bad I don't have time to go deeper into these issues

ciao -- Nando

[Klaus Spanderen]

Hi Nando,

might be we are talking about different things here. The
LiborForwardModelProcess does have multiple different (correlated)
underlyings as it is a multidimensional stochastic process following the SDE
given by the LFM

One possible parameterization of the covariance matrices of a LFM-process is
the LfmHullWhiteParameterization class, which uses the market data container
CapletVarianceCurve to get todays spot caplet volatilities for a given period
length. They are needed to bootstrapp internal parameters, which define the
covariance matrices. std::vector<Volatility> would work instead of
CapletVarianceCurve. Using this class lazy users don't have to define a
caplet volatility for each and every fixing date. Instead linear
interpolation of the caplet variances is used and BlackVarianceCurve is in
charge for this operations.

> Klaus wrote:
> > I would suggest that we either remove the constraint or I'll doublicate
> > the functionalilty needed in CapletVarianceCurve. Nando, your advice?
>
> I would definitely design a dedicated class for caplet variance. I
> suggest to digest Rebonato's discussion about it as guideline.

hmm. The intention of CapletVarianceCurve was to have a market data container
for spot caplet volatilities for different terms and a given period length.
(No link to libor market models.). The class LmVolatilityModel is used to
model the volatilities within a libor forward model (process). I guess this
is what you are behind as it defines for each time a vector of volatilities
for the different underlying of a libor forward model process.

cheers
 Klaus

[Klaus Spanderen]

Hi

You wrote:
>Is it possible to add a further constructor that may take a cashflow array
>(instead of constructing this internally). This array may represent the
>floating rates of a forward swap (say 5Y into 5Y).

No problem for the LfmProcess but a lot of the downstream classes - especially
the implied market calibration classes in
ql/ShortRateModels/LiborMarketModels - don't support adjustments for irregular
fixing schedules. I don't want to create a illusion of flexibility, which is
currently not supported by most of the classes. Therefore (at the time being)
I've encapsulated the cash flow scheduling to ensure regular fixings.

You wrote
>Thus from the current implementation, if one wanted to price a 5Y into 5Y
>ratchet cap, one would have to simulate the Libors from Spot into 10Y, but
>discard the first 5 years!!!

Make the implementation more flexible to allow forward starting LFM processes
having regular fixings is on my todo list for 0.3.13. For 0.3.12 I just
wanted to get the implied market calibration runing to enable market
calibration instead of the "weak" caplet-bootstrapping in
LfmHullWhiteParameterization.

You wrote
>This may be a silly question so please forgive me but why is the first
>forward rate (constructed within the LiborForwardModelProcess class)
>actually there?

Valid question. To me it is a matter of taste. You are right there is no need
to have it in the MC simulation. As soon as forward starting processes are
supported they can be removed by rolling the starting date forward.

cheers  
        Klaus

[Ferdinando M. Ametrano-3]

On 3/8/06, Klaus Spanderen <[hidden email]> wrote:
> todays spot caplet volatilities [...] are needed to bootstrapp internal parameters,
> which define the [LMM] covariance matrices. std::vector<Volatility> would work
> instead of CapletVarianceCurve.
agreed. The square of the elements of that vector multiplied with
their respective expiry times (i.e. caplet variances) are NOT required
to be an increasing function of time.

> Using this [BlackVarianceCurve ] class lazy users don't have to define a
> caplet volatility for each and every fixing date. Instead linear
> interpolation of the caplet variances is used and BlackVarianceCurve is in
> charge for this operations.
BlackVarianceCurve is the wrong class for this task. The apparent
similar interface between  BlackVarianceCurve and the caplet vol
interpolator should not hide the fact that we're concened about the
variance of a single factor vs the variance of many factors. For a
single factor variances must be an increasing function of time: this
is an intrinsic constaint and it is the main rationale behind the
BlackVarianceCurve class. This same rationale means that
BlackVarianceCurve should not be used for caplet variances

> > I suggest to digest Rebonato's discussion about it as guideline.
>
> hmm. The intention of CapletVarianceCurve was to have a market data container
> for spot caplet volatilities for different terms and a given period length.
> (No link to libor market models.).
Rebonato's discussion I'm referring to is about spot caplet vol
constraints. He shows that if caplet variances are an increasing
fuction of time this has nothing to do with the intrinsic constraint
for single factor, but it is related to time-homogenous evolution of
the multifactor caplet variances. These results are indipendent of any
modelling assumption.

> The class LmVolatilityModel is used to
> model the volatilities within a libor forward model (process). I guess this
> is what you are behind as it defines for each time a vector of volatilities
> for the different underlying of a libor forward model process.
If I got it right LmVolatilityModel is the LMM core dynamic. The class
for caplet variance might be std::vector<Volatility> plus an
interpolation method, without further constraints.

ciao -- nando

[Klaus Spanderen]

Hi Toyin,

On Wednesday 08 March 2006 4:39 am, Toyin Akin wrote:
> Thus from the current implementation, if one wanted to price a 5Y into 5Y
> ratchet cap, one would have to simulate the Libors from Spot into 10Y, but
> discard the first 5 years!!!

The first 5 years are needed to define the discount factors for a path as you
stated. Unless you don't want to use an approximation (IMO) we have to
simulate them if you want to have todays npv.

To speed-up the simulation, LiborForwardModelProcess::evolve is the best
starting point. The predictor-correction step is implmented within 3 line -
short, only possible in Quantlib - but this implementation is pretty slow.
Rolling out this calculation will speed-up the MC-Simulations by a factor 2-5
I guess. Give me time over the weekend, I'll check this out.

cheers
 Klaus