|
From: Peter C. <pca...@vo...> - 2012-05-27 19:28:43
|
Hi Ferdinando, Mark, Klaus,
I am working in a project where we want to make use of the ql (1.1)
implementation of the stochastic volatility libor forward model. The
product we want to price is an exotic swap with payoff depending on
Euribor6m and EUR CMS20y rates. The natural choice for the "rateTimes"
therefore seems to be a 6m grid. The rates however are observed on a
quarterly grid. My understanding is that I can choose the
"evolutionTimes" possibly different from the rateTimes representing the
needed fixing times. This is what I get from the description in
evolutiondescription.hpp:
-# evolutionTimes = the times defining the rates that are to be evolved,
-# rateTimes = the times at which the rates need to be known,
-# relevanceRates = which rates need to be known at each time.
...
I believe the explanations for evolutionTimes and rateTimes are switched
here.
The model I am using is AbcdVol(...). The observation is that the
swaptions from the calibration basket are greatly overpriced in the
simulation. I think this is due to the particular choice of the
evolutionTimes grid being strictly finer than the rateTimes grid (which
is equal to the correlation times grid coming from a
TimeHomogeneousForwardCorrelation). This case is in my opinion not
handled correctly when computing the covariance matrices for the
evolution steps in the constructor of AbcdVol. To put it more precisely
the underlying time intervals [effStartTime, effStopTime] are
overlapping due to wrong left interval points then, thus leading to too
high covariances (consistent with the observation of too high simulated
swaption prices).
Here is my proposal to fix that in abcdvol.cpp
AbcdVol::AbcdVol(
Real a,
Real b,
@@ -67,24 +69,25 @@ namespace QuantLib {
"number of factors (" << numberOfFactors <<
") must be greater than zero");
AbcdFunction abcd(a, b, c, d);
Real covar;
- Time effStartTime, effStopTime;
+ Time effStartTime, effStopTime=0;
Real correlation;
const std::vector<Time>& corrTimes = corr->times();
const std::vector<Time>& evolTimes = evolution.evolutionTimes();
for (Size k=0, kk=0; k<numberOfSteps_; ++k) {
// one covariance per evolution step
Matrix covariance(numberOfRates_, numberOfRates_, 0.0);
// there might be more than one correlation matrix
// in a single evolution step
Matrix correlations;
for (; corrTimes[kk]<evolTimes[k]; ++kk) {
- effStartTime = kk==0 ? 0.0 : corrTimes[kk-1];
+ effStartTime = effStopTime;
effStopTime = corrTimes[kk];
correlations = corr->correlation(kk);
for (Size i=0; i<numberOfRates_; ++i) {
for (Size j=i; j<numberOfRates_; ++j) {
covar = ks[i] * ks[j] *
abcd.covariance(effStartTime,
@@ -95,11 +98,11 @@ namespace QuantLib {
covariance[i][j] += covar * correlation;
}
}
}
// last part in the evolution step
- effStartTime = kk==0 ? 0.0 : corrTimes[kk-1];
+ effStartTime = effStopTime;
effStopTime = evolTimes[k];
correlations = corr->correlation(kk);
for (Size i=0; i<numberOfRates_; ++i) {
for (Size j=i; j<numberOfRates_; ++j) {
covar = ks[i] * ks[j] * abcd.covariance(effStartTime,
Do you think this is correct and complete? The testsuite shows no
differences at least and results are much better after these changes.
Thanks a lot
Peter
|
|
From: Peter C. <pca...@vo...> - 2012-08-07 18:38:55
Attachments:
Nachrichtenteil als Anhang
|
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ |
|
From: Ferdinando A. <na...@am...> - 2012-09-03 15:20:25
|
Hi Peter > [...] the particular choice of the evolutionTimes grid being > strictly finer than the rateTimes grid (which is equal to the correlation > times grid coming from a TimeHomogeneousForwardCorrelation). This case is in > my opinion not handled correctly when computing the covariance matrices for > the evolution steps in the constructor of AbcdVol. yes, you're right: I've just committed your bug-fix to both AbcdVol and FlatVol (which was affected too). Thank you and sorry it took so long. Any chance you might contribute a unit test to avoid regressions? I am thinking about a simple flat vol (and degenerate abcd vol with a=b=c=0.0) test case where for N evolution times there are 1, N, 2N, 2N+1 correlation matrices, checking that total variances are correct ciao -- Nando |
|
From: Peter C. <pca...@gm...> - 2012-09-08 13:38:31
|
Hi Nando, I added a test case to the marketmodel suite. In fact while doing this I noticed that AbcdFunction::primitive(...) fails when c is zero. I fixed that and added another test case covering this. Peter > Hi Peter > >> [...] the particular choice of the evolutionTimes grid being >> strictly finer than the rateTimes grid (which is equal to the correlation >> times grid coming from a TimeHomogeneousForwardCorrelation). This case is in >> my opinion not handled correctly when computing the covariance matrices for >> the evolution steps in the constructor of AbcdVol. > yes, you're right: I've just committed your bug-fix to both AbcdVol > and FlatVol (which was affected too). > Thank you and sorry it took so long. > > Any chance you might contribute a unit test to avoid regressions? I am > thinking about a simple flat vol (and degenerate abcd vol with > a=b=c=0.0) test case where for N evolution times there are 1, N, 2N, > 2N+1 correlation matrices, checking that total variances are correct > > ciao -- Nando |
|
From: Luigi B. <lui...@gm...> - 2012-10-24 15:22:29
|
I've added the fix and the tests, thanks. Luigi On Sat, Sep 8, 2012 at 3:38 PM, Peter Caspers <pca...@gm...> wrote: > Hi Nando, > > I added a test case to the marketmodel suite. > > In fact while doing this I noticed that AbcdFunction::primitive(...) fails > when c is zero. I fixed that and added another test case covering this. > > Peter > > >> Hi Peter >> >>> [...] the particular choice of the evolutionTimes grid being >>> strictly finer than the rateTimes grid (which is equal to the correlation >>> times grid coming from a TimeHomogeneousForwardCorrelation). This case is >>> in >>> my opinion not handled correctly when computing the covariance matrices >>> for >>> the evolution steps in the constructor of AbcdVol. >> >> yes, you're right: I've just committed your bug-fix to both AbcdVol >> and FlatVol (which was affected too). >> Thank you and sorry it took so long. >> >> Any chance you might contribute a unit test to avoid regressions? I am >> thinking about a simple flat vol (and degenerate abcd vol with >> a=b=c=0.0) test case where for N evolution times there are 1, N, 2N, >> 2N+1 correlation matrices, checking that total variances are correct >> >> ciao -- Nando > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > |