MakeCms Capped Rate

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

MakeCms Capped Rate

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

Re: MakeCms Capped Rate

Ferdinando M. Ametrano-2

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

Re: MakeCms Capped Rate

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

Re: MakeCms Capped Rate

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

Re: MakeCms Capped Rate

Ferdinando M. Ametrano-2
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:
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
Reply | Threaded
Open this post in threaded view
|

Re: MakeCms Capped Rate

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