MakeCms Capped Rate
Locked
 
|
Hi,
is there a reason that the standard cms swaps constructed with MakeCms have a capped rate at 200% ? https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/instruments/makecms.cpp#L43 If no one objects I would like to send a pull request to remove the cap. This might impact results in existing code though, so I thought I better ask here. Thank you Peter ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: MakeCms Capped Rate
|
|
Mmm... I seem to remember something about the only existing model at the time having issues on integrating the smile up to infinitum. On Feb 17, 2014 8:36 PM, "Peter Caspers" <[hidden email]> wrote:
Hi, ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
I don't know, but if the issue is still there, shouldn't we better fix
it in the NumericHaganPricer by introducing a hard upper integration bound at 2 ? Peter On 18 February 2014 07:51, Ferdinando M. Ametrano <[hidden email]> wrote: > Mmm... I seem to remember something about the only existing model at the > time having issues on integrating the smile up to infinitum. > Is this not the case anymore? > > On Feb 17, 2014 8:36 PM, "Peter Caspers" <[hidden email]> wrote: >> >> Hi, >> >> is there a reason that the standard cms swaps constructed with MakeCms >> have a capped rate >> at 200% ? >> >> >> https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/instruments/makecms.cpp#L43 >> >> If no one objects I would like to send a pull request to remove the >> cap. This might impact results >> in existing code though, so I thought I better ask here. >> >> Thank you >> Peter >> >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> _______________________________________________ >> QuantLib-dev mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Yes, I'd fix it downstream rather than in the instrument.
Luigi On Tue, Feb 18, 2014 at 9:48 AM, Peter Caspers <[hidden email]> wrote: > I don't know, but if the issue is still there, shouldn't we better fix > it in the NumericHaganPricer by introducing a hard upper integration > bound at 2 ? > Peter > > > On 18 February 2014 07:51, Ferdinando M. Ametrano > <[hidden email]> wrote: >> Mmm... I seem to remember something about the only existing model at the >> time having issues on integrating the smile up to infinitum. >> Is this not the case anymore? >> >> On Feb 17, 2014 8:36 PM, "Peter Caspers" <[hidden email]> wrote: >>> >>> Hi, >>> >>> is there a reason that the standard cms swaps constructed with MakeCms >>> have a capped rate >>> at 200% ? >>> >>> >>> https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/instruments/makecms.cpp#L43 >>> >>> If no one objects I would like to send a pull request to remove the >>> cap. This might impact results >>> in existing code though, so I thought I better ask here. >>> >>> Thank you >>> Peter >>> >>> >>> ------------------------------------------------------------------------------ >>> Managing the Performance of Cloud-Based Applications >>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >>> Read the Whitepaper. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> QuantLib-dev mailing list >>> [hidden email] >>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&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> ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: MakeCms Capped Rate
|
|
In reply to this post by Peter Caspers-4
Peter, I am currently not using that code in my day-by-day and have little time to investigate: I'll just trust your judgement. by the way, thank you for all your contributions in the recent months, you've really stepped your game up
ciao -- Nando On Tue, Feb 18, 2014 at 9:48 AM, Peter Caspers <[hidden email]> wrote:
------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
thank you, Nando. I did some further testing on this. The test cases
in CmsTest run fine also without the capped rate in MakeCms. So no immediate need for further fixes. However you can really stress test the NumericHaganPricer with the wrong smile input: 1 flat yield 3%, SABR vol alpha=0.15, beta=0.80, rho=-0.30, nu =1.80, cms10y coupon with fixing in 19y, payment in 20y (GFunction = Standard) => seg fault (wow!) 2 same with nu = 0.80 => max func eval exceeded (although set to 10^6) It seems #1 is caused by too many recursive calls within GaussKronrodAdaptive. Lowering the max eval parameter seems to solve this issue. I guess we should fix that in every case. #2 is not avoidable with the current integration strategy, but introducing a hard upper limit for the integration simply produces a result no matter how extreme the vol input is. Therefore I would suggest to introduce such a hard upper limit, set it to QL_MAX_REAL by default (so no change in the pricer's behaviour by default) and leave it to the user to plug in something like 200% to ensure that the code runs through without throwing exceptions and returns some reasonable result. Both #1 and #2 are not avoided by the MakeCms capped rate of course. I guess this was maybe inserted to limit exploding adjustments for certain vol inputs. But this can also be achieved by the hard upper bound proposed above. I will send a pull request in this direction (i.e. remove the capped rate from MakeCms, fix the seg fault case, provide a hard upper limit defaulted to max real). Does it make sense ? Peter On 18 February 2014 09:54, Ferdinando M. Ametrano <[hidden email]> wrote: > Peter, > > I am currently not using that code in my day-by-day and have little time to > investigate: I'll just trust your judgement. > > by the way, thank you for all your contributions in the recent months, > you've really stepped your game up > > ciao -- Nando > > > On Tue, Feb 18, 2014 at 9:48 AM, Peter Caspers <[hidden email]> > wrote: >> >> I don't know, but if the issue is still there, shouldn't we better fix >> it in the NumericHaganPricer by introducing a hard upper integration >> bound at 2 ? >> Peter >> >> >> On 18 February 2014 07:51, Ferdinando M. Ametrano >> <[hidden email]> wrote: >> > Mmm... I seem to remember something about the only existing model at the >> > time having issues on integrating the smile up to infinitum. >> > Is this not the case anymore? >> > >> > On Feb 17, 2014 8:36 PM, "Peter Caspers" <[hidden email]> wrote: >> >> >> >> Hi, >> >> >> >> is there a reason that the standard cms swaps constructed with MakeCms >> >> have a capped rate >> >> at 200% ? >> >> >> >> >> >> >> >> https://github.com/lballabio/quantlib/blob/master/QuantLib/ql/instruments/makecms.cpp#L43 >> >> >> >> If no one objects I would like to send a pull request to remove the >> >> cap. This might impact results >> >> in existing code though, so I thought I better ask here. >> >> >> >> Thank you >> >> Peter >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Managing the Performance of Cloud-Based Applications >> >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> >> Read the Whitepaper. >> >> >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> QuantLib-dev mailing list >> >> [hidden email] >> >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |