Posted by
Peter Caspers-4 on
Feb 19, 2014; 5:57pm
URL: http://quantlib.414.s1.nabble.com/MakeCms-Capped-Rate-tp14976p14998.html
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