quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] FW: SABR regression

[Luigi B. <lui...@gm...>]

No, I think long is 32 bits too.

How about simply checking the hash against two different values depending
on the size of std::size_t?


On Wed, Nov 19, 2014 at 10:25 AM, Peter Caspers <pca...@gm...>
wrote:

> std::size_t could be the problem (noarbsabr.cpp L329), is that 32 Bit
> under VC9 ? Should we use usigned long instead, is that always 64 Bit ?
>
> On 19 November 2014 09:43, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> It only fails on VC++9.  NoArbSabrTest::testAbsorptionMatrix fails to
>> verify the hash value of the absorption matrix.
>>
>> On Wed, Nov 19, 2014 at 6:43 AM, Peter Caspers <pca...@gm...>
>> wrote:
>>
>>> oops. For me the test suite in the current master both with and without
>>> #170 runs fine. Only the new regression case included in 170 fails without
>>> the patch. Let me know what error pops up on your side.
>>> Peter
>>>
>>>
>>>
>>> On 18 November 2014 21:57, Ferdinando M. Ametrano <na...@am...>
>>> wrote:
>>>
>>>> wow, this was fast!
>>>> btw by "sabr test" I meant one test in the QuantlIb test suite
>>>>
>>>> On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>>> Alright, I added a test case for the regression you found and one for
>>>>> the direct/inverse functions (a deterministic one, yes). I'll have a look
>>>>> at your data and see if we can extract more interesting test cases from
>>>>> that.
>>>>>
>>>>> And please send the new case when you are back.
>>>>>
>>>>> Peter
>>>>>
>>>>> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
>>>>> wrote:
>>>>>
>>>>>> Yes Peter, I can provide a caplet snapshot for a test.
>>>>>>
>>>>>> As for a direct/inverse test: yes please, but avoid random numbers as
>>>>>> that would make tests unpredictable.
>>>>>>
>>>>>> Please also note that one sabr test is currently failing: I don't
>>>>>> know if because of yesterday's patch or it has been failing for a while.
>>>>>> thurdays, back at my desk,  I can provide more details, but you might want
>>>>>> to check it up on your setup in the meantime
>>>>>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> yes, please send an example (otherwise I could already take the one
>>>>>>> from the excel you sent earlier ? or was that made up ?). In addtion I
>>>>>>> think I should add a technical test like
>>>>>>>
>>>>>>> for random input x
>>>>>>> - y = direct(x) generates admissable values
>>>>>>> - direct( inverse( y ) ) = y
>>>>>>>
>>>>>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <
>>>>>>> na...@am...> wrote:
>>>>>>>
>>>>>>>> Thank you Peter for the timely fix.
>>>>>>>>
>>>>>>>> One takeaway is to create a unit test to check for possible future
>>>>>>>> regressions.
>>>>>>>> Do you have a relevant dataset from some paper to suggest? If not,
>>>>>>>> I could provide a snapshot of current euro caplets.
>>>>>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>>>>>> pao...@es...> wrote:
>>>>>>>>
>>>>>>>>>  Hi Peter,
>>>>>>>>>
>>>>>>>>> I tested your modifications and they work properly. The results
>>>>>>>>> are in line with the ones obtained using QL 1.2.
>>>>>>>>>
>>>>>>>>> Anyway, the details (forward and time to expiry) are written in
>>>>>>>>> the excel file attached in the previous email.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> time
>>>>>>>>>
>>>>>>>>> fwd
>>>>>>>>>
>>>>>>>>> 0.1342
>>>>>>>>>
>>>>>>>>> 1.1075%
>>>>>>>>>
>>>>>>>>> 0.3833
>>>>>>>>>
>>>>>>>>> 1.1025%
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you very much for your help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Paolo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Paolo Mazzocchi*
>>>>>>>>>
>>>>>>>>> *Deloitte Consulting Srl*
>>>>>>>>>
>>>>>>>>> consulente di
>>>>>>>>>
>>>>>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>>>>>
>>>>>>>>> Tel: 02-72615029  Int: 35029
>>>>>>>>>
>>>>>>>>> *pao...@es... <pao...@es...>*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>>>>>> *To:* Ferdinando M. Ametrano
>>>>>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Ferdinando,
>>>>>>>>>
>>>>>>>>> I pushed a fix here (effectively it should yield the same results
>>>>>>>>> as the file attached earlier)
>>>>>>>>>
>>>>>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>>>>>
>>>>>>>>> As far as I remember the reason for the change in the
>>>>>>>>> transformation function (for 1.3 or 1.4 ?) were nan / inf values occuring
>>>>>>>>> from time to time in the calibration. This is why I replaced the parabolas
>>>>>>>>> by truncated parabolas with linear wings (such that the result is C^1).
>>>>>>>>>
>>>>>>>>> If you feel that your test case is still working better in 1.2,
>>>>>>>>> could you please send some more details (forward, time to expiry), I'd be
>>>>>>>>> happy to discuss again then.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Ferdinando,
>>>>>>>>>
>>>>>>>>> one problem is the transformation function direct(...) which is
>>>>>>>>> buggy for alpha and nu. Can you try the attached version instead and see if
>>>>>>>>> it works better ?
>>>>>>>>>
>>>>>>>>> I'd like to have a closer look and try on more cases before I send
>>>>>>>>> a PR though.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <
>>>>>>>>> na...@am...> wrote:
>>>>>>>>>
>>>>>>>>> Hi Peter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SABR implementation on the current trunk has a regression compared
>>>>>>>>> with QuantLib 1.2.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> While trying to calibrate problematic smiles as:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> strike
>>>>>>>>>
>>>>>>>>> 1.00%
>>>>>>>>>
>>>>>>>>> 1.13%
>>>>>>>>>
>>>>>>>>> 1.25%
>>>>>>>>>
>>>>>>>>> 1.38%
>>>>>>>>>
>>>>>>>>> 1.50%
>>>>>>>>>
>>>>>>>>> vol1
>>>>>>>>>
>>>>>>>>> 23.20%
>>>>>>>>>
>>>>>>>>> 20.25%
>>>>>>>>>
>>>>>>>>> 31.21%
>>>>>>>>>
>>>>>>>>> 39.02%
>>>>>>>>>
>>>>>>>>> 50.45%
>>>>>>>>>
>>>>>>>>> vol2
>>>>>>>>>
>>>>>>>>> 16.67%
>>>>>>>>>
>>>>>>>>> 20.20%
>>>>>>>>>
>>>>>>>>> 27.85%
>>>>>>>>>
>>>>>>>>> 32.79%
>>>>>>>>>
>>>>>>>>> 37.27%
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> max error
>>>>>>>>>
>>>>>>>>> rms error
>>>>>>>>>
>>>>>>>>> end criteria
>>>>>>>>>
>>>>>>>>> alpha
>>>>>>>>>
>>>>>>>>> beta
>>>>>>>>>
>>>>>>>>> nu
>>>>>>>>>
>>>>>>>>> rho
>>>>>>>>>
>>>>>>>>> 1.79%
>>>>>>>>>
>>>>>>>>> 0.94%
>>>>>>>>>
>>>>>>>>>  StationaryPoint
>>>>>>>>>
>>>>>>>>> 0.58%
>>>>>>>>>
>>>>>>>>> 25.00%
>>>>>>>>>
>>>>>>>>> 346.03%
>>>>>>>>>
>>>>>>>>> 34.19%
>>>>>>>>>
>>>>>>>>> 0.65%
>>>>>>>>>
>>>>>>>>> 0.43%
>>>>>>>>>
>>>>>>>>> StationaryPoint
>>>>>>>>>
>>>>>>>>> 0.62%
>>>>>>>>>
>>>>>>>>> 25.00%
>>>>>>>>>
>>>>>>>>> 193.97%
>>>>>>>>>
>>>>>>>>> 63.66%
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the current trunk instead fails for the second smile with error
>>>>>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If one tries to just use the four leftmost volatilities to
>>>>>>>>> simplify the problem, both calibrations fail with the same error. This
>>>>>>>>> leads me to believe the problem is about the solver looking for a solution
>>>>>>>>> in the negative nu region. If this is the case it could be solved having a
>>>>>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please find attached a spreadsheet reproducing the error. We might
>>>>>>>>> even want to add a non regression test to the test suite.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thank you for your help
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>>
>>>>>>>>> F
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Prima di stampare, pensa all'ambiente ** Think about the
>>>>>>>>> environment before printing
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>>
>>>>>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>>>>>> mittente e di cancellarlo.
>>>>>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione
>>>>>>>>> o diffusione non autorizzata del contenuto di questo messaggio o di parte
>>>>>>>>> di esso.
>>>>>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al
>>>>>>>>> minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>>>>>> presenza di virus.
>>>>>>>>>
>>>>>>>>> Per lo svolgimento delle attività di investimento nel Regno Unito,
>>>>>>>>> la società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>>>>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>>>>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>>>>>>
>>>>>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale
>>>>>>>>> di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in
>>>>>>>>> Inghilterra & Galles sotto No.FC016201, Branch No.BR000036
>>>>>>>>>
>>>>>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>>>>>> indirizzata ad un altro destinatario.
>>>>>>>>>
>>>>>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>>>>>> Irlanda.
>>>>>>>>>
>>>>>>>>> ***
>>>>>>>>>
>>>>>>>>> ------------------------------
>>>>>>>>>
>>>>>>>>> This email (including any attachment) is a corporate message and
>>>>>>>>> may contain confidential and/or privileged and/or proprietary information.
>>>>>>>>> If you have received this email in error, please notify the sender
>>>>>>>>> immediately, do not use or share it and destroy this email. Any
>>>>>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>>>>>> We have taken precautions to minimize the risk of transmitting
>>>>>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>>>>>> or damage caused by software viruses.
>>>>>>>>>
>>>>>>>>> For the conduct of investment business in the UK, the Company is
>>>>>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>>>>>> ( PRA ) are available from us on request.
>>>>>>>>>
>>>>>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London
>>>>>>>>> Branch, located at 90 Queen Street, London EC4N 1SA. Registered in England
>>>>>>>>> & Wales under No.FC016201, Branch No.BR000036
>>>>>>>>>
>>>>>>>>> To comply with requirements imposed by the IRS, we inform you that
>>>>>>>>> any discussion of U.S. federal tax issues contained herein (including any
>>>>>>>>> attachments) was not intended or written to be used, and cannot be used by
>>>>>>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>>>>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>>>>>>> addressed herein to another party.
>>>>>>>>>
>>>>>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>>>>>> IFSC, Dublin 1, Ireland.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>>
>>
>>
>> --
>> <https://implementingquantlib.blogspot.com>
>> <https://twitter.com/lballabio>
>>
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

[Quantlib-dev] Fwd: FW: SABR regression

[Peter C. <pca...@gm...>]

deleting the body, which grew over 50kb ...
---------- Forwarded message ----------
From: Peter Caspers <pca...@gm...>
Date: 19 November 2014 10:36
Subject: Re: [Quantlib-dev] FW: SABR regression
To: Luigi Ballabio <lui...@gm...>
Cc: "Ferdinando M. Ametrano" <na...@am...>, "maz...@li..." <
maz...@li...>, maddalena zanzi <mad...@gm...>, QuantLib
Mailing Lists <qua...@li...>


ah sorry, I am so bad at this. I guess it is only important, that
std::size_t and long have the same size (actually both seem to be 4 bytes
under VC10 whilst 8 under gcc, maybe this is in addtion dependent on
whether -m64 is used ?). Replacing std::size_t by long in L329 should do
the trick, I think ? I don't have VC9, so I can not try ...
Peter

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

std::size_t could be the problem (noarbsabr.cpp L329), is that 32 Bit under
VC9 ? Should we use usigned long instead, is that always 64 Bit ?

On 19 November 2014 09:43, Luigi Ballabio <lui...@gm...> wrote:

> It only fails on VC++9.  NoArbSabrTest::testAbsorptionMatrix fails to
> verify the hash value of the absorption matrix.
>
> On Wed, Nov 19, 2014 at 6:43 AM, Peter Caspers <pca...@gm...>
> wrote:
>
>> oops. For me the test suite in the current master both with and without
>> #170 runs fine. Only the new regression case included in 170 fails without
>> the patch. Let me know what error pops up on your side.
>> Peter
>>
>>
>>
>> On 18 November 2014 21:57, Ferdinando M. Ametrano <na...@am...>
>> wrote:
>>
>>> wow, this was fast!
>>> btw by "sabr test" I meant one test in the QuantlIb test suite
>>>
>>> On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...>
>>> wrote:
>>>
>>>> Alright, I added a test case for the regression you found and one for
>>>> the direct/inverse functions (a deterministic one, yes). I'll have a look
>>>> at your data and see if we can extract more interesting test cases from
>>>> that.
>>>>
>>>> And please send the new case when you are back.
>>>>
>>>> Peter
>>>>
>>>> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
>>>> wrote:
>>>>
>>>>> Yes Peter, I can provide a caplet snapshot for a test.
>>>>>
>>>>> As for a direct/inverse test: yes please, but avoid random numbers as
>>>>> that would make tests unpredictable.
>>>>>
>>>>> Please also note that one sabr test is currently failing: I don't know
>>>>> if because of yesterday's patch or it has been failing for a while.
>>>>> thurdays, back at my desk,  I can provide more details, but you might want
>>>>> to check it up on your setup in the meantime
>>>>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...>
>>>>> wrote:
>>>>>
>>>>>> yes, please send an example (otherwise I could already take the one
>>>>>> from the excel you sent earlier ? or was that made up ?). In addtion I
>>>>>> think I should add a technical test like
>>>>>>
>>>>>> for random input x
>>>>>> - y = direct(x) generates admissable values
>>>>>> - direct( inverse( y ) ) = y
>>>>>>
>>>>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...
>>>>>> > wrote:
>>>>>>
>>>>>>> Thank you Peter for the timely fix.
>>>>>>>
>>>>>>> One takeaway is to create a unit test to check for possible future
>>>>>>> regressions.
>>>>>>> Do you have a relevant dataset from some paper to suggest? If not, I
>>>>>>> could provide a snapshot of current euro caplets.
>>>>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>>>>> pao...@es...> wrote:
>>>>>>>
>>>>>>>>  Hi Peter,
>>>>>>>>
>>>>>>>> I tested your modifications and they work properly. The results are
>>>>>>>> in line with the ones obtained using QL 1.2.
>>>>>>>>
>>>>>>>> Anyway, the details (forward and time to expiry) are written in the
>>>>>>>> excel file attached in the previous email.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> time
>>>>>>>>
>>>>>>>> fwd
>>>>>>>>
>>>>>>>> 0.1342
>>>>>>>>
>>>>>>>> 1.1075%
>>>>>>>>
>>>>>>>> 0.3833
>>>>>>>>
>>>>>>>> 1.1025%
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you very much for your help.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Paolo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Paolo Mazzocchi*
>>>>>>>>
>>>>>>>> *Deloitte Consulting Srl*
>>>>>>>>
>>>>>>>> consulente di
>>>>>>>>
>>>>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>>>>
>>>>>>>> Tel: 02-72615029  Int: 35029
>>>>>>>>
>>>>>>>> *pao...@es... <pao...@es...>*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>>>>> *To:* Ferdinando M. Ametrano
>>>>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Ferdinando,
>>>>>>>>
>>>>>>>> I pushed a fix here (effectively it should yield the same results
>>>>>>>> as the file attached earlier)
>>>>>>>>
>>>>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>>>>
>>>>>>>> As far as I remember the reason for the change in the
>>>>>>>> transformation function (for 1.3 or 1.4 ?) were nan / inf values occuring
>>>>>>>> from time to time in the calibration. This is why I replaced the parabolas
>>>>>>>> by truncated parabolas with linear wings (such that the result is C^1).
>>>>>>>>
>>>>>>>> If you feel that your test case is still working better in 1.2,
>>>>>>>> could you please send some more details (forward, time to expiry), I'd be
>>>>>>>> happy to discuss again then.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Ferdinando,
>>>>>>>>
>>>>>>>> one problem is the transformation function direct(...) which is
>>>>>>>> buggy for alpha and nu. Can you try the attached version instead and see if
>>>>>>>> it works better ?
>>>>>>>>
>>>>>>>> I'd like to have a closer look and try on more cases before I send
>>>>>>>> a PR though.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <
>>>>>>>> na...@am...> wrote:
>>>>>>>>
>>>>>>>> Hi Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> SABR implementation on the current trunk has a regression compared
>>>>>>>> with QuantLib 1.2.1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> While trying to calibrate problematic smiles as:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> strike
>>>>>>>>
>>>>>>>> 1.00%
>>>>>>>>
>>>>>>>> 1.13%
>>>>>>>>
>>>>>>>> 1.25%
>>>>>>>>
>>>>>>>> 1.38%
>>>>>>>>
>>>>>>>> 1.50%
>>>>>>>>
>>>>>>>> vol1
>>>>>>>>
>>>>>>>> 23.20%
>>>>>>>>
>>>>>>>> 20.25%
>>>>>>>>
>>>>>>>> 31.21%
>>>>>>>>
>>>>>>>> 39.02%
>>>>>>>>
>>>>>>>> 50.45%
>>>>>>>>
>>>>>>>> vol2
>>>>>>>>
>>>>>>>> 16.67%
>>>>>>>>
>>>>>>>> 20.20%
>>>>>>>>
>>>>>>>> 27.85%
>>>>>>>>
>>>>>>>> 32.79%
>>>>>>>>
>>>>>>>> 37.27%
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> max error
>>>>>>>>
>>>>>>>> rms error
>>>>>>>>
>>>>>>>> end criteria
>>>>>>>>
>>>>>>>> alpha
>>>>>>>>
>>>>>>>> beta
>>>>>>>>
>>>>>>>> nu
>>>>>>>>
>>>>>>>> rho
>>>>>>>>
>>>>>>>> 1.79%
>>>>>>>>
>>>>>>>> 0.94%
>>>>>>>>
>>>>>>>>  StationaryPoint
>>>>>>>>
>>>>>>>> 0.58%
>>>>>>>>
>>>>>>>> 25.00%
>>>>>>>>
>>>>>>>> 346.03%
>>>>>>>>
>>>>>>>> 34.19%
>>>>>>>>
>>>>>>>> 0.65%
>>>>>>>>
>>>>>>>> 0.43%
>>>>>>>>
>>>>>>>> StationaryPoint
>>>>>>>>
>>>>>>>> 0.62%
>>>>>>>>
>>>>>>>> 25.00%
>>>>>>>>
>>>>>>>> 193.97%
>>>>>>>>
>>>>>>>> 63.66%
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> the current trunk instead fails for the second smile with error
>>>>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If one tries to just use the four leftmost volatilities to simplify
>>>>>>>> the problem, both calibrations fail with the same error. This leads me to
>>>>>>>> believe the problem is about the solver looking for a solution in the
>>>>>>>> negative nu region. If this is the case it could be solved having a
>>>>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please find attached a spreadsheet reproducing the error. We might
>>>>>>>> even want to add a non regression test to the test suite.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> thank you for your help
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> regards
>>>>>>>>
>>>>>>>> F
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Prima di stampare, pensa all'ambiente ** Think about the
>>>>>>>> environment before printing
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>>>>> mittente e di cancellarlo.
>>>>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>>>>>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>>>>>>> esso.
>>>>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al
>>>>>>>> minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>>>>> presenza di virus.
>>>>>>>>
>>>>>>>> Per lo svolgimento delle attività di investimento nel Regno Unito,
>>>>>>>> la società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>>>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>>>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>>>>>
>>>>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale
>>>>>>>> di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in
>>>>>>>> Inghilterra & Galles sotto No.FC016201, Branch No.BR000036
>>>>>>>>
>>>>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>>>>> indirizzata ad un altro destinatario.
>>>>>>>>
>>>>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>>>>> Irlanda.
>>>>>>>>
>>>>>>>> ***
>>>>>>>>
>>>>>>>> ------------------------------
>>>>>>>>
>>>>>>>> This email (including any attachment) is a corporate message and
>>>>>>>> may contain confidential and/or privileged and/or proprietary information.
>>>>>>>> If you have received this email in error, please notify the sender
>>>>>>>> immediately, do not use or share it and destroy this email. Any
>>>>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>>>>> We have taken precautions to minimize the risk of transmitting
>>>>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>>>>> or damage caused by software viruses.
>>>>>>>>
>>>>>>>> For the conduct of investment business in the UK, the Company is
>>>>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>>>>> ( PRA ) are available from us on request.
>>>>>>>>
>>>>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London
>>>>>>>> Branch, located at 90 Queen Street, London EC4N 1SA. Registered in England
>>>>>>>> & Wales under No.FC016201, Branch No.BR000036
>>>>>>>>
>>>>>>>> To comply with requirements imposed by the IRS, we inform you that
>>>>>>>> any discussion of U.S. federal tax issues contained herein (including any
>>>>>>>> attachments) was not intended or written to be used, and cannot be used by
>>>>>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>>>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>>>>>> addressed herein to another party.
>>>>>>>>
>>>>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>>>>> IFSC, Dublin 1, Ireland.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>
>
> --
> <https://implementingquantlib.blogspot.com>
> <https://twitter.com/lballabio>
>

Re: [Quantlib-dev] FW: SABR regression

[Luigi B. <lui...@gm...>]

It only fails on VC++9.  NoArbSabrTest::testAbsorptionMatrix fails to
verify the hash value of the absorption matrix.

On Wed, Nov 19, 2014 at 6:43 AM, Peter Caspers <pca...@gm...>
wrote:

> oops. For me the test suite in the current master both with and without
> #170 runs fine. Only the new regression case included in 170 fails without
> the patch. Let me know what error pops up on your side.
> Peter
>
>
>
> On 18 November 2014 21:57, Ferdinando M. Ametrano <na...@am...>
> wrote:
>
>> wow, this was fast!
>> btw by "sabr test" I meant one test in the QuantlIb test suite
>>
>> On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...>
>> wrote:
>>
>>> Alright, I added a test case for the regression you found and one for
>>> the direct/inverse functions (a deterministic one, yes). I'll have a look
>>> at your data and see if we can extract more interesting test cases from
>>> that.
>>>
>>> And please send the new case when you are back.
>>>
>>> Peter
>>>
>>> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
>>> wrote:
>>>
>>>> Yes Peter, I can provide a caplet snapshot for a test.
>>>>
>>>> As for a direct/inverse test: yes please, but avoid random numbers as
>>>> that would make tests unpredictable.
>>>>
>>>> Please also note that one sabr test is currently failing: I don't know
>>>> if because of yesterday's patch or it has been failing for a while.
>>>> thurdays, back at my desk,  I can provide more details, but you might want
>>>> to check it up on your setup in the meantime
>>>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...>
>>>> wrote:
>>>>
>>>>> yes, please send an example (otherwise I could already take the one
>>>>> from the excel you sent earlier ? or was that made up ?). In addtion I
>>>>> think I should add a technical test like
>>>>>
>>>>> for random input x
>>>>> - y = direct(x) generates admissable values
>>>>> - direct( inverse( y ) ) = y
>>>>>
>>>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
>>>>> wrote:
>>>>>
>>>>>> Thank you Peter for the timely fix.
>>>>>>
>>>>>> One takeaway is to create a unit test to check for possible future
>>>>>> regressions.
>>>>>> Do you have a relevant dataset from some paper to suggest? If not, I
>>>>>> could provide a snapshot of current euro caplets.
>>>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>>>> pao...@es...> wrote:
>>>>>>
>>>>>>>  Hi Peter,
>>>>>>>
>>>>>>> I tested your modifications and they work properly. The results are
>>>>>>> in line with the ones obtained using QL 1.2.
>>>>>>>
>>>>>>> Anyway, the details (forward and time to expiry) are written in the
>>>>>>> excel file attached in the previous email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> time
>>>>>>>
>>>>>>> fwd
>>>>>>>
>>>>>>> 0.1342
>>>>>>>
>>>>>>> 1.1075%
>>>>>>>
>>>>>>> 0.3833
>>>>>>>
>>>>>>> 1.1025%
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thank you very much for your help.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Paolo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Paolo Mazzocchi*
>>>>>>>
>>>>>>> *Deloitte Consulting Srl*
>>>>>>>
>>>>>>> consulente di
>>>>>>>
>>>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>>>
>>>>>>> Tel: 02-72615029  Int: 35029
>>>>>>>
>>>>>>> *pao...@es... <pao...@es...>*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>>>> *To:* Ferdinando M. Ametrano
>>>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Ferdinando,
>>>>>>>
>>>>>>> I pushed a fix here (effectively it should yield the same results as
>>>>>>> the file attached earlier)
>>>>>>>
>>>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>>>
>>>>>>> As far as I remember the reason for the change in the transformation
>>>>>>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>>>>>>> time in the calibration. This is why I replaced the parabolas by truncated
>>>>>>> parabolas with linear wings (such that the result is C^1).
>>>>>>>
>>>>>>> If you feel that your test case is still working better in 1.2,
>>>>>>> could you please send some more details (forward, time to expiry), I'd be
>>>>>>> happy to discuss again then.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Ferdinando,
>>>>>>>
>>>>>>> one problem is the transformation function direct(...) which is
>>>>>>> buggy for alpha and nu. Can you try the attached version instead and see if
>>>>>>> it works better ?
>>>>>>>
>>>>>>> I'd like to have a closer look and try on more cases before I send a
>>>>>>> PR though.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <
>>>>>>> na...@am...> wrote:
>>>>>>>
>>>>>>> Hi Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> SABR implementation on the current trunk has a regression compared
>>>>>>> with QuantLib 1.2.1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> While trying to calibrate problematic smiles as:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> strike
>>>>>>>
>>>>>>> 1.00%
>>>>>>>
>>>>>>> 1.13%
>>>>>>>
>>>>>>> 1.25%
>>>>>>>
>>>>>>> 1.38%
>>>>>>>
>>>>>>> 1.50%
>>>>>>>
>>>>>>> vol1
>>>>>>>
>>>>>>> 23.20%
>>>>>>>
>>>>>>> 20.25%
>>>>>>>
>>>>>>> 31.21%
>>>>>>>
>>>>>>> 39.02%
>>>>>>>
>>>>>>> 50.45%
>>>>>>>
>>>>>>> vol2
>>>>>>>
>>>>>>> 16.67%
>>>>>>>
>>>>>>> 20.20%
>>>>>>>
>>>>>>> 27.85%
>>>>>>>
>>>>>>> 32.79%
>>>>>>>
>>>>>>> 37.27%
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> max error
>>>>>>>
>>>>>>> rms error
>>>>>>>
>>>>>>> end criteria
>>>>>>>
>>>>>>> alpha
>>>>>>>
>>>>>>> beta
>>>>>>>
>>>>>>> nu
>>>>>>>
>>>>>>> rho
>>>>>>>
>>>>>>> 1.79%
>>>>>>>
>>>>>>> 0.94%
>>>>>>>
>>>>>>>  StationaryPoint
>>>>>>>
>>>>>>> 0.58%
>>>>>>>
>>>>>>> 25.00%
>>>>>>>
>>>>>>> 346.03%
>>>>>>>
>>>>>>> 34.19%
>>>>>>>
>>>>>>> 0.65%
>>>>>>>
>>>>>>> 0.43%
>>>>>>>
>>>>>>> StationaryPoint
>>>>>>>
>>>>>>> 0.62%
>>>>>>>
>>>>>>> 25.00%
>>>>>>>
>>>>>>> 193.97%
>>>>>>>
>>>>>>> 63.66%
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> the current trunk instead fails for the second smile with error
>>>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If one tries to just use the four leftmost volatilities to simplify
>>>>>>> the problem, both calibrations fail with the same error. This leads me to
>>>>>>> believe the problem is about the solver looking for a solution in the
>>>>>>> negative nu region. If this is the case it could be solved having a
>>>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please find attached a spreadsheet reproducing the error. We might
>>>>>>> even want to add a non regression test to the test suite.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> thank you for your help
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> regards
>>>>>>>
>>>>>>> F
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Prima di stampare, pensa all'ambiente ** Think about the environment
>>>>>>> before printing
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>>>> mittente e di cancellarlo.
>>>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>>>>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>>>>>> esso.
>>>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al
>>>>>>> minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>>>> presenza di virus.
>>>>>>>
>>>>>>> Per lo svolgimento delle attività di investimento nel Regno Unito,
>>>>>>> la società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>>>>
>>>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale
>>>>>>> di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in
>>>>>>> Inghilterra & Galles sotto No.FC016201, Branch No.BR000036
>>>>>>>
>>>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>>>> indirizzata ad un altro destinatario.
>>>>>>>
>>>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>>>> Irlanda.
>>>>>>>
>>>>>>> ***
>>>>>>>
>>>>>>> ------------------------------
>>>>>>>
>>>>>>> This email (including any attachment) is a corporate message and may
>>>>>>> contain confidential and/or privileged and/or proprietary information. If
>>>>>>> you have received this email in error, please notify the sender
>>>>>>> immediately, do not use or share it and destroy this email. Any
>>>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>>>> We have taken precautions to minimize the risk of transmitting
>>>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>>>> or damage caused by software viruses.
>>>>>>>
>>>>>>> For the conduct of investment business in the UK, the Company is
>>>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>>>> ( PRA ) are available from us on request.
>>>>>>>
>>>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>>>>>>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>>>>>>> under No.FC016201, Branch No.BR000036
>>>>>>>
>>>>>>> To comply with requirements imposed by the IRS, we inform you that
>>>>>>> any discussion of U.S. federal tax issues contained herein (including any
>>>>>>> attachments) was not intended or written to be used, and cannot be used by
>>>>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>>>>> addressed herein to another party.
>>>>>>>
>>>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>>>> IFSC, Dublin 1, Ireland.
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

oops. For me the test suite in the current master both with and without
#170 runs fine. Only the new regression case included in 170 fails without
the patch. Let me know what error pops up on your side.
Peter



On 18 November 2014 21:57, Ferdinando M. Ametrano <na...@am...>
wrote:

> wow, this was fast!
> btw by "sabr test" I meant one test in the QuantlIb test suite
>
> On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...>
> wrote:
>
>> Alright, I added a test case for the regression you found and one for the
>> direct/inverse functions (a deterministic one, yes). I'll have a look at
>> your data and see if we can extract more interesting test cases from that.
>>
>> And please send the new case when you are back.
>>
>> Peter
>>
>> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
>> wrote:
>>
>>> Yes Peter, I can provide a caplet snapshot for a test.
>>>
>>> As for a direct/inverse test: yes please, but avoid random numbers as
>>> that would make tests unpredictable.
>>>
>>> Please also note that one sabr test is currently failing: I don't know
>>> if because of yesterday's patch or it has been failing for a while.
>>> thurdays, back at my desk,  I can provide more details, but you might want
>>> to check it up on your setup in the meantime
>>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...> wrote:
>>>
>>>> yes, please send an example (otherwise I could already take the one
>>>> from the excel you sent earlier ? or was that made up ?). In addtion I
>>>> think I should add a technical test like
>>>>
>>>> for random input x
>>>> - y = direct(x) generates admissable values
>>>> - direct( inverse( y ) ) = y
>>>>
>>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>>
>>>> Peter
>>>>
>>>>
>>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
>>>> wrote:
>>>>
>>>>> Thank you Peter for the timely fix.
>>>>>
>>>>> One takeaway is to create a unit test to check for possible future
>>>>> regressions.
>>>>> Do you have a relevant dataset from some paper to suggest? If not, I
>>>>> could provide a snapshot of current euro caplets.
>>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>>> pao...@es...> wrote:
>>>>>
>>>>>>  Hi Peter,
>>>>>>
>>>>>> I tested your modifications and they work properly. The results are
>>>>>> in line with the ones obtained using QL 1.2.
>>>>>>
>>>>>> Anyway, the details (forward and time to expiry) are written in the
>>>>>> excel file attached in the previous email.
>>>>>>
>>>>>>
>>>>>>
>>>>>> time
>>>>>>
>>>>>> fwd
>>>>>>
>>>>>> 0.1342
>>>>>>
>>>>>> 1.1075%
>>>>>>
>>>>>> 0.3833
>>>>>>
>>>>>> 1.1025%
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you very much for your help.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Paolo Mazzocchi*
>>>>>>
>>>>>> *Deloitte Consulting Srl*
>>>>>>
>>>>>> consulente di
>>>>>>
>>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>>
>>>>>> Tel: 02-72615029  Int: 35029
>>>>>>
>>>>>> *pao...@es... <pao...@es...>*
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>>> *To:* Ferdinando M. Ametrano
>>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Ferdinando,
>>>>>>
>>>>>> I pushed a fix here (effectively it should yield the same results as
>>>>>> the file attached earlier)
>>>>>>
>>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>>
>>>>>> As far as I remember the reason for the change in the transformation
>>>>>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>>>>>> time in the calibration. This is why I replaced the parabolas by truncated
>>>>>> parabolas with linear wings (such that the result is C^1).
>>>>>>
>>>>>> If you feel that your test case is still working better in 1.2, could
>>>>>> you please send some more details (forward, time to expiry), I'd be happy
>>>>>> to discuss again then.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Ferdinando,
>>>>>>
>>>>>> one problem is the transformation function direct(...) which is buggy
>>>>>> for alpha and nu. Can you try the attached version instead and see if it
>>>>>> works better ?
>>>>>>
>>>>>> I'd like to have a closer look and try on more cases before I send a
>>>>>> PR though.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>> SABR implementation on the current trunk has a regression compared
>>>>>> with QuantLib 1.2.1
>>>>>>
>>>>>>
>>>>>>
>>>>>> While trying to calibrate problematic smiles as:
>>>>>>
>>>>>>
>>>>>>
>>>>>> strike
>>>>>>
>>>>>> 1.00%
>>>>>>
>>>>>> 1.13%
>>>>>>
>>>>>> 1.25%
>>>>>>
>>>>>> 1.38%
>>>>>>
>>>>>> 1.50%
>>>>>>
>>>>>> vol1
>>>>>>
>>>>>> 23.20%
>>>>>>
>>>>>> 20.25%
>>>>>>
>>>>>> 31.21%
>>>>>>
>>>>>> 39.02%
>>>>>>
>>>>>> 50.45%
>>>>>>
>>>>>> vol2
>>>>>>
>>>>>> 16.67%
>>>>>>
>>>>>> 20.20%
>>>>>>
>>>>>> 27.85%
>>>>>>
>>>>>> 32.79%
>>>>>>
>>>>>> 37.27%
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>>
>>>>>>
>>>>>>
>>>>>> max error
>>>>>>
>>>>>> rms error
>>>>>>
>>>>>> end criteria
>>>>>>
>>>>>> alpha
>>>>>>
>>>>>> beta
>>>>>>
>>>>>> nu
>>>>>>
>>>>>> rho
>>>>>>
>>>>>> 1.79%
>>>>>>
>>>>>> 0.94%
>>>>>>
>>>>>>  StationaryPoint
>>>>>>
>>>>>> 0.58%
>>>>>>
>>>>>> 25.00%
>>>>>>
>>>>>> 346.03%
>>>>>>
>>>>>> 34.19%
>>>>>>
>>>>>> 0.65%
>>>>>>
>>>>>> 0.43%
>>>>>>
>>>>>> StationaryPoint
>>>>>>
>>>>>> 0.62%
>>>>>>
>>>>>> 25.00%
>>>>>>
>>>>>> 193.97%
>>>>>>
>>>>>> 63.66%
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> the current trunk instead fails for the second smile with error
>>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>>
>>>>>>
>>>>>>
>>>>>> If one tries to just use the four leftmost volatilities to simplify
>>>>>> the problem, both calibrations fail with the same error. This leads me to
>>>>>> believe the problem is about the solver looking for a solution in the
>>>>>> negative nu region. If this is the case it could be solved having a
>>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please find attached a spreadsheet reproducing the error. We might
>>>>>> even want to add a non regression test to the test suite.
>>>>>>
>>>>>>
>>>>>>
>>>>>> thank you for your help
>>>>>>
>>>>>>
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> F
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Prima di stampare, pensa all'ambiente ** Think about the environment
>>>>>> before printing
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>>> mittente e di cancellarlo.
>>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>>>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>>>>> esso.
>>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al minimo
>>>>>> il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>>> presenza di virus.
>>>>>>
>>>>>> Per lo svolgimento delle attività di investimento nel Regno Unito, la
>>>>>> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>>>
>>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
>>>>>> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
>>>>>> & Galles sotto No.FC016201, Branch No.BR000036
>>>>>>
>>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>>> indirizzata ad un altro destinatario.
>>>>>>
>>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>>> Irlanda.
>>>>>>
>>>>>> ***
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> This email (including any attachment) is a corporate message and may
>>>>>> contain confidential and/or privileged and/or proprietary information. If
>>>>>> you have received this email in error, please notify the sender
>>>>>> immediately, do not use or share it and destroy this email. Any
>>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>>> We have taken precautions to minimize the risk of transmitting
>>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>>> or damage caused by software viruses.
>>>>>>
>>>>>> For the conduct of investment business in the UK, the Company is
>>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>>> ( PRA ) are available from us on request.
>>>>>>
>>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>>>>>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>>>>>> under No.FC016201, Branch No.BR000036
>>>>>>
>>>>>> To comply with requirements imposed by the IRS, we inform you that
>>>>>> any discussion of U.S. federal tax issues contained herein (including any
>>>>>> attachments) was not intended or written to be used, and cannot be used by
>>>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>>>> addressed herein to another party.
>>>>>>
>>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>>> IFSC, Dublin 1, Ireland.
>>>>>>
>>>>>
>>>>
>>
>

Re: [Quantlib-dev] FW: SABR regression

[Ferdinando M. A. <na...@am...>]

wow, this was fast!
btw by "sabr test" I meant one test in the QuantlIb test suite

On Tue, Nov 18, 2014 at 9:47 PM, Peter Caspers <pca...@gm...>
wrote:

> Alright, I added a test case for the regression you found and one for the
> direct/inverse functions (a deterministic one, yes). I'll have a look at
> your data and see if we can extract more interesting test cases from that.
>
> And please send the new case when you are back.
>
> Peter
>
> On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
> wrote:
>
>> Yes Peter, I can provide a caplet snapshot for a test.
>>
>> As for a direct/inverse test: yes please, but avoid random numbers as
>> that would make tests unpredictable.
>>
>> Please also note that one sabr test is currently failing: I don't know if
>> because of yesterday's patch or it has been failing for a while. thurdays,
>> back at my desk,  I can provide more details, but you might want to check
>> it up on your setup in the meantime
>> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...> wrote:
>>
>>> yes, please send an example (otherwise I could already take the one from
>>> the excel you sent earlier ? or was that made up ?). In addtion I think I
>>> should add a technical test like
>>>
>>> for random input x
>>> - y = direct(x) generates admissable values
>>> - direct( inverse( y ) ) = y
>>>
>>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>>
>>> Peter
>>>
>>>
>>> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
>>> wrote:
>>>
>>>> Thank you Peter for the timely fix.
>>>>
>>>> One takeaway is to create a unit test to check for possible future
>>>> regressions.
>>>> Do you have a relevant dataset from some paper to suggest? If not, I
>>>> could provide a snapshot of current euro caplets.
>>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>>> pao...@es...> wrote:
>>>>
>>>>>  Hi Peter,
>>>>>
>>>>> I tested your modifications and they work properly. The results are in
>>>>> line with the ones obtained using QL 1.2.
>>>>>
>>>>> Anyway, the details (forward and time to expiry) are written in the
>>>>> excel file attached in the previous email.
>>>>>
>>>>>
>>>>>
>>>>> time
>>>>>
>>>>> fwd
>>>>>
>>>>> 0.1342
>>>>>
>>>>> 1.1075%
>>>>>
>>>>> 0.3833
>>>>>
>>>>> 1.1025%
>>>>>
>>>>>
>>>>>
>>>>> Thank you very much for your help.
>>>>>
>>>>>
>>>>>
>>>>> Paolo
>>>>>
>>>>>
>>>>>
>>>>> *Paolo Mazzocchi*
>>>>>
>>>>> *Deloitte Consulting Srl*
>>>>>
>>>>> consulente di
>>>>>
>>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>>
>>>>> Tel: 02-72615029  Int: 35029
>>>>>
>>>>> *pao...@es... <pao...@es...>*
>>>>>
>>>>>
>>>>>
>>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>>> *To:* Ferdinando M. Ametrano
>>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>>
>>>>>
>>>>>
>>>>> Hi Ferdinando,
>>>>>
>>>>> I pushed a fix here (effectively it should yield the same results as
>>>>> the file attached earlier)
>>>>>
>>>>> https://github.com/lballabio/quantlib/pull/170
>>>>>
>>>>> As far as I remember the reason for the change in the transformation
>>>>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>>>>> time in the calibration. This is why I replaced the parabolas by truncated
>>>>> parabolas with linear wings (such that the result is C^1).
>>>>>
>>>>> If you feel that your test case is still working better in 1.2, could
>>>>> you please send some more details (forward, time to expiry), I'd be happy
>>>>> to discuss again then.
>>>>>
>>>>>
>>>>>
>>>>> Best regards
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>>> wrote:
>>>>>
>>>>> Hi Ferdinando,
>>>>>
>>>>> one problem is the transformation function direct(...) which is buggy
>>>>> for alpha and nu. Can you try the attached version instead and see if it
>>>>> works better ?
>>>>>
>>>>> I'd like to have a closer look and try on more cases before I send a
>>>>> PR though.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
>>>>> wrote:
>>>>>
>>>>> Hi Peter
>>>>>
>>>>>
>>>>>
>>>>> SABR implementation on the current trunk has a regression compared
>>>>> with QuantLib 1.2.1
>>>>>
>>>>>
>>>>>
>>>>> While trying to calibrate problematic smiles as:
>>>>>
>>>>>
>>>>>
>>>>> strike
>>>>>
>>>>> 1.00%
>>>>>
>>>>> 1.13%
>>>>>
>>>>> 1.25%
>>>>>
>>>>> 1.38%
>>>>>
>>>>> 1.50%
>>>>>
>>>>> vol1
>>>>>
>>>>> 23.20%
>>>>>
>>>>> 20.25%
>>>>>
>>>>> 31.21%
>>>>>
>>>>> 39.02%
>>>>>
>>>>> 50.45%
>>>>>
>>>>> vol2
>>>>>
>>>>> 16.67%
>>>>>
>>>>> 20.20%
>>>>>
>>>>> 27.85%
>>>>>
>>>>> 32.79%
>>>>>
>>>>> 37.27%
>>>>>
>>>>>
>>>>>
>>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>>
>>>>>
>>>>>
>>>>> max error
>>>>>
>>>>> rms error
>>>>>
>>>>> end criteria
>>>>>
>>>>> alpha
>>>>>
>>>>> beta
>>>>>
>>>>> nu
>>>>>
>>>>> rho
>>>>>
>>>>> 1.79%
>>>>>
>>>>> 0.94%
>>>>>
>>>>>  StationaryPoint
>>>>>
>>>>> 0.58%
>>>>>
>>>>> 25.00%
>>>>>
>>>>> 346.03%
>>>>>
>>>>> 34.19%
>>>>>
>>>>> 0.65%
>>>>>
>>>>> 0.43%
>>>>>
>>>>> StationaryPoint
>>>>>
>>>>> 0.62%
>>>>>
>>>>> 25.00%
>>>>>
>>>>> 193.97%
>>>>>
>>>>> 63.66%
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> the current trunk instead fails for the second smile with error
>>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>>
>>>>>
>>>>>
>>>>> If one tries to just use the four leftmost volatilities to simplify
>>>>> the problem, both calibrations fail with the same error. This leads me to
>>>>> believe the problem is about the solver looking for a solution in the
>>>>> negative nu region. If this is the case it could be solved having a
>>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>>
>>>>>
>>>>>
>>>>> Please find attached a spreadsheet reproducing the error. We might
>>>>> even want to add a non regression test to the test suite.
>>>>>
>>>>>
>>>>>
>>>>> thank you for your help
>>>>>
>>>>>
>>>>>
>>>>> regards
>>>>>
>>>>> F
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Prima di stampare, pensa all'ambiente ** Think about the environment
>>>>> before printing
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>>> mittente e di cancellarlo.
>>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>>>> esso.
>>>>> Pur essendo state assunte le dovute precauzioni per ridurre al minimo
>>>>> il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>>> presenza di virus.
>>>>>
>>>>> Per lo svolgimento delle attività di investimento nel Regno Unito, la
>>>>> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>>
>>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
>>>>> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
>>>>> & Galles sotto No.FC016201, Branch No.BR000036
>>>>>
>>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>>> indirizzata ad un altro destinatario.
>>>>>
>>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>>> Irlanda.
>>>>>
>>>>> ***
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> This email (including any attachment) is a corporate message and may
>>>>> contain confidential and/or privileged and/or proprietary information. If
>>>>> you have received this email in error, please notify the sender
>>>>> immediately, do not use or share it and destroy this email. Any
>>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>>> We have taken precautions to minimize the risk of transmitting
>>>>> software viruses but nevertheless advise you to carry out your own virus
>>>>> checks on any attachment of this message. We accept no liability for loss
>>>>> or damage caused by software viruses.
>>>>>
>>>>> For the conduct of investment business in the UK, the Company is
>>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>>> ( PRA ) are available from us on request.
>>>>>
>>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>>>>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>>>>> under No.FC016201, Branch No.BR000036
>>>>>
>>>>> To comply with requirements imposed by the IRS, we inform you that any
>>>>> discussion of U.S. federal tax issues contained herein (including any
>>>>> attachments) was not intended or written to be used, and cannot be used by
>>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>>> addressed herein to another party.
>>>>>
>>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>>> IFSC, Dublin 1, Ireland.
>>>>>
>>>>
>>>
>

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

Alright, I added a test case for the regression you found and one for the
direct/inverse functions (a deterministic one, yes). I'll have a look at
your data and see if we can extract more interesting test cases from that.

And please send the new case when you are back.

Peter

On 18 November 2014 20:31, Ferdinando M. Ametrano <na...@am...>
wrote:

> Yes Peter, I can provide a caplet snapshot for a test.
>
> As for a direct/inverse test: yes please, but avoid random numbers as that
> would make tests unpredictable.
>
> Please also note that one sabr test is currently failing: I don't know if
> because of yesterday's patch or it has been failing for a while. thurdays,
> back at my desk,  I can provide more details, but you might want to check
> it up on your setup in the meantime
> On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...> wrote:
>
>> yes, please send an example (otherwise I could already take the one from
>> the excel you sent earlier ? or was that made up ?). In addtion I think I
>> should add a technical test like
>>
>> for random input x
>> - y = direct(x) generates admissable values
>> - direct( inverse( y ) ) = y
>>
>> for sabr, noarbsabr, zabr and svi. What do you think ?
>>
>> Peter
>>
>>
>> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
>> wrote:
>>
>>> Thank you Peter for the timely fix.
>>>
>>> One takeaway is to create a unit test to check for possible future
>>> regressions.
>>> Do you have a relevant dataset from some paper to suggest? If not, I
>>> could provide a snapshot of current euro caplets.
>>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>>> pao...@es...> wrote:
>>>
>>>>  Hi Peter,
>>>>
>>>> I tested your modifications and they work properly. The results are in
>>>> line with the ones obtained using QL 1.2.
>>>>
>>>> Anyway, the details (forward and time to expiry) are written in the
>>>> excel file attached in the previous email.
>>>>
>>>>
>>>>
>>>> time
>>>>
>>>> fwd
>>>>
>>>> 0.1342
>>>>
>>>> 1.1075%
>>>>
>>>> 0.3833
>>>>
>>>> 1.1025%
>>>>
>>>>
>>>>
>>>> Thank you very much for your help.
>>>>
>>>>
>>>>
>>>> Paolo
>>>>
>>>>
>>>>
>>>> *Paolo Mazzocchi*
>>>>
>>>> *Deloitte Consulting Srl*
>>>>
>>>> consulente di
>>>>
>>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>>
>>>> Tel: 02-72615029  Int: 35029
>>>>
>>>> *pao...@es... <pao...@es...>*
>>>>
>>>>
>>>>
>>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>>> *To:* Ferdinando M. Ametrano
>>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>>
>>>>
>>>>
>>>> Hi Ferdinando,
>>>>
>>>> I pushed a fix here (effectively it should yield the same results as
>>>> the file attached earlier)
>>>>
>>>> https://github.com/lballabio/quantlib/pull/170
>>>>
>>>> As far as I remember the reason for the change in the transformation
>>>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>>>> time in the calibration. This is why I replaced the parabolas by truncated
>>>> parabolas with linear wings (such that the result is C^1).
>>>>
>>>> If you feel that your test case is still working better in 1.2, could
>>>> you please send some more details (forward, time to expiry), I'd be happy
>>>> to discuss again then.
>>>>
>>>>
>>>>
>>>> Best regards
>>>> Peter
>>>>
>>>>
>>>>
>>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>> Hi Ferdinando,
>>>>
>>>> one problem is the transformation function direct(...) which is buggy
>>>> for alpha and nu. Can you try the attached version instead and see if it
>>>> works better ?
>>>>
>>>> I'd like to have a closer look and try on more cases before I send a PR
>>>> though.
>>>>
>>>> Thanks
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
>>>> wrote:
>>>>
>>>> Hi Peter
>>>>
>>>>
>>>>
>>>> SABR implementation on the current trunk has a regression compared with
>>>> QuantLib 1.2.1
>>>>
>>>>
>>>>
>>>> While trying to calibrate problematic smiles as:
>>>>
>>>>
>>>>
>>>> strike
>>>>
>>>> 1.00%
>>>>
>>>> 1.13%
>>>>
>>>> 1.25%
>>>>
>>>> 1.38%
>>>>
>>>> 1.50%
>>>>
>>>> vol1
>>>>
>>>> 23.20%
>>>>
>>>> 20.25%
>>>>
>>>> 31.21%
>>>>
>>>> 39.02%
>>>>
>>>> 50.45%
>>>>
>>>> vol2
>>>>
>>>> 16.67%
>>>>
>>>> 20.20%
>>>>
>>>> 27.85%
>>>>
>>>> 32.79%
>>>>
>>>> 37.27%
>>>>
>>>>
>>>>
>>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>>
>>>>
>>>>
>>>> max error
>>>>
>>>> rms error
>>>>
>>>> end criteria
>>>>
>>>> alpha
>>>>
>>>> beta
>>>>
>>>> nu
>>>>
>>>> rho
>>>>
>>>> 1.79%
>>>>
>>>> 0.94%
>>>>
>>>>  StationaryPoint
>>>>
>>>> 0.58%
>>>>
>>>> 25.00%
>>>>
>>>> 346.03%
>>>>
>>>> 34.19%
>>>>
>>>> 0.65%
>>>>
>>>> 0.43%
>>>>
>>>> StationaryPoint
>>>>
>>>> 0.62%
>>>>
>>>> 25.00%
>>>>
>>>> 193.97%
>>>>
>>>> 63.66%
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> the current trunk instead fails for the second smile with error
>>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>>
>>>>
>>>>
>>>> If one tries to just use the four leftmost volatilities to simplify the
>>>> problem, both calibrations fail with the same error. This leads me to
>>>> believe the problem is about the solver looking for a solution in the
>>>> negative nu region. If this is the case it could be solved having a
>>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>>
>>>>
>>>>
>>>> Please find attached a spreadsheet reproducing the error. We might even
>>>> want to add a non regression test to the test suite.
>>>>
>>>>
>>>>
>>>> thank you for your help
>>>>
>>>>
>>>>
>>>> regards
>>>>
>>>> F
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Prima di stampare, pensa all'ambiente ** Think about the environment
>>>> before printing
>>>>
>>>> ------------------------------
>>>>
>>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>>> mittente e di cancellarlo.
>>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>>> esso.
>>>> Pur essendo state assunte le dovute precauzioni per ridurre al minimo
>>>> il rischio di trasmissione di virus, si suggerisce di effettuare gli
>>>> opportuni controlli sui documenti allegati al presente messaggio. Non si
>>>> assume alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>>> presenza di virus.
>>>>
>>>> Per lo svolgimento delle attività di investimento nel Regno Unito, la
>>>> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>>
>>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
>>>> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
>>>> & Galles sotto No.FC016201, Branch No.BR000036
>>>>
>>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>>> indirizzata ad un altro destinatario.
>>>>
>>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>>> Irlanda.
>>>>
>>>> ***
>>>>
>>>> ------------------------------
>>>>
>>>> This email (including any attachment) is a corporate message and may
>>>> contain confidential and/or privileged and/or proprietary information. If
>>>> you have received this email in error, please notify the sender
>>>> immediately, do not use or share it and destroy this email. Any
>>>> unauthorised use, copying or disclosure of the material in this email or of
>>>> parts hereof (including reliance thereon) is strictly forbidden.
>>>> We have taken precautions to minimize the risk of transmitting software
>>>> viruses but nevertheless advise you to carry out your own virus checks on
>>>> any attachment of this message. We accept no liability for loss or damage
>>>> caused by software viruses.
>>>>
>>>> For the conduct of investment business in the UK, the Company is
>>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>>> Authority ( PRA ). Details about the extent of our regulation by the
>>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>>> ( PRA ) are available from us on request.
>>>>
>>>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>>>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>>>> under No.FC016201, Branch No.BR000036
>>>>
>>>> To comply with requirements imposed by the IRS, we inform you that any
>>>> discussion of U.S. federal tax issues contained herein (including any
>>>> attachments) was not intended or written to be used, and cannot be used by
>>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>>> addressed herein to another party.
>>>>
>>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>>> IFSC, Dublin 1, Ireland.
>>>>
>>>
>>

Re: [Quantlib-dev] FW: SABR regression

[Ferdinando M. A. <na...@am...>]

Yes Peter, I can provide a caplet snapshot for a test.

As for a direct/inverse test: yes please, but avoid random numbers as that
would make tests unpredictable.

Please also note that one sabr test is currently failing: I don't know if
because of yesterday's patch or it has been failing for a while. thurdays,
back at my desk,  I can provide more details, but you might want to check
it up on your setup in the meantime
On Nov 18, 2014 9:33 AM, "Peter Caspers" <pca...@gm...> wrote:

> yes, please send an example (otherwise I could already take the one from
> the excel you sent earlier ? or was that made up ?). In addtion I think I
> should add a technical test like
>
> for random input x
> - y = direct(x) generates admissable values
> - direct( inverse( y ) ) = y
>
> for sabr, noarbsabr, zabr and svi. What do you think ?
>
> Peter
>
>
> On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
> wrote:
>
>> Thank you Peter for the timely fix.
>>
>> One takeaway is to create a unit test to check for possible future
>> regressions.
>> Do you have a relevant dataset from some paper to suggest? If not, I
>> could provide a snapshot of current euro caplets.
>> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
>> pao...@es...> wrote:
>>
>>>  Hi Peter,
>>>
>>> I tested your modifications and they work properly. The results are in
>>> line with the ones obtained using QL 1.2.
>>>
>>> Anyway, the details (forward and time to expiry) are written in the
>>> excel file attached in the previous email.
>>>
>>>
>>>
>>> time
>>>
>>> fwd
>>>
>>> 0.1342
>>>
>>> 1.1075%
>>>
>>> 0.3833
>>>
>>> 1.1025%
>>>
>>>
>>>
>>> Thank you very much for your help.
>>>
>>>
>>>
>>> Paolo
>>>
>>>
>>>
>>> *Paolo Mazzocchi*
>>>
>>> *Deloitte Consulting Srl*
>>>
>>> consulente di
>>>
>>> *FINANCIAL ENGINEERING - Banca IMI*
>>>
>>> Tel: 02-72615029  Int: 35029
>>>
>>> *pao...@es... <pao...@es...>*
>>>
>>>
>>>
>>> *From:* Peter Caspers [mailto:pca...@gm...]
>>> *Sent:* Monday, November 17, 2014 7:00 PM
>>> *To:* Ferdinando M. Ametrano
>>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>>
>>>
>>>
>>> Hi Ferdinando,
>>>
>>> I pushed a fix here (effectively it should yield the same results as the
>>> file attached earlier)
>>>
>>> https://github.com/lballabio/quantlib/pull/170
>>>
>>> As far as I remember the reason for the change in the transformation
>>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>>> time in the calibration. This is why I replaced the parabolas by truncated
>>> parabolas with linear wings (such that the result is C^1).
>>>
>>> If you feel that your test case is still working better in 1.2, could
>>> you please send some more details (forward, time to expiry), I'd be happy
>>> to discuss again then.
>>>
>>>
>>>
>>> Best regards
>>> Peter
>>>
>>>
>>>
>>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...> wrote:
>>>
>>> Hi Ferdinando,
>>>
>>> one problem is the transformation function direct(...) which is buggy
>>> for alpha and nu. Can you try the attached version instead and see if it
>>> works better ?
>>>
>>> I'd like to have a closer look and try on more cases before I send a PR
>>> though.
>>>
>>> Thanks
>>>
>>> Peter
>>>
>>>
>>>
>>> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
>>> wrote:
>>>
>>> Hi Peter
>>>
>>>
>>>
>>> SABR implementation on the current trunk has a regression compared with
>>> QuantLib 1.2.1
>>>
>>>
>>>
>>> While trying to calibrate problematic smiles as:
>>>
>>>
>>>
>>> strike
>>>
>>> 1.00%
>>>
>>> 1.13%
>>>
>>> 1.25%
>>>
>>> 1.38%
>>>
>>> 1.50%
>>>
>>> vol1
>>>
>>> 23.20%
>>>
>>> 20.25%
>>>
>>> 31.21%
>>>
>>> 39.02%
>>>
>>> 50.45%
>>>
>>> vol2
>>>
>>> 16.67%
>>>
>>> 20.20%
>>>
>>> 27.85%
>>>
>>> 32.79%
>>>
>>> 37.27%
>>>
>>>
>>>
>>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>>
>>>
>>>
>>> max error
>>>
>>> rms error
>>>
>>> end criteria
>>>
>>> alpha
>>>
>>> beta
>>>
>>> nu
>>>
>>> rho
>>>
>>> 1.79%
>>>
>>> 0.94%
>>>
>>>  StationaryPoint
>>>
>>> 0.58%
>>>
>>> 25.00%
>>>
>>> 346.03%
>>>
>>> 34.19%
>>>
>>> 0.65%
>>>
>>> 0.43%
>>>
>>> StationaryPoint
>>>
>>> 0.62%
>>>
>>> 25.00%
>>>
>>> 193.97%
>>>
>>> 63.66%
>>>
>>>
>>>
>>>
>>>
>>> the current trunk instead fails for the second smile with error
>>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>>
>>>
>>>
>>> If one tries to just use the four leftmost volatilities to simplify the
>>> problem, both calibrations fail with the same error. This leads me to
>>> believe the problem is about the solver looking for a solution in the
>>> negative nu region. If this is the case it could be solved having a
>>> positive constraint for nu. Do you agree? Could you please look into it?
>>>
>>>
>>>
>>> Please find attached a spreadsheet reproducing the error. We might even
>>> want to add a non regression test to the test suite.
>>>
>>>
>>>
>>> thank you for your help
>>>
>>>
>>>
>>> regards
>>>
>>> F
>>>
>>>
>>>
>>>
>>>
>>>
>>> Prima di stampare, pensa all'ambiente ** Think about the environment
>>> before printing
>>>
>>> ------------------------------
>>>
>>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>>> mittente e di cancellarlo.
>>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>>> esso.
>>> Pur essendo state assunte le dovute precauzioni per ridurre al minimo il
>>> rischio di trasmissione di virus, si suggerisce di effettuare gli opportuni
>>> controlli sui documenti allegati al presente messaggio. Non si assume
>>> alcuna responsabilità per eventuali danni o perdite derivanti dalla
>>> presenza di virus.
>>>
>>> Per lo svolgimento delle attività di investimento nel Regno Unito, la
>>> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>>
>>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
>>> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
>>> & Galles sotto No.FC016201, Branch No.BR000036
>>>
>>> In osservanza dei requisito imposti dal Internal Revenue Service
>>> (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a
>>> temi di natura fiscale contenuta in questo messaggio o nei suoi allegati
>>> non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>>> indirizzata ad un altro destinatario.
>>>
>>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>>> Irlanda.
>>>
>>> ***
>>>
>>> ------------------------------
>>>
>>> This email (including any attachment) is a corporate message and may
>>> contain confidential and/or privileged and/or proprietary information. If
>>> you have received this email in error, please notify the sender
>>> immediately, do not use or share it and destroy this email. Any
>>> unauthorised use, copying or disclosure of the material in this email or of
>>> parts hereof (including reliance thereon) is strictly forbidden.
>>> We have taken precautions to minimize the risk of transmitting software
>>> viruses but nevertheless advise you to carry out your own virus checks on
>>> any attachment of this message. We accept no liability for loss or damage
>>> caused by software viruses.
>>>
>>> For the conduct of investment business in the UK, the Company is
>>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>>> Authority ( PRA ). Details about the extent of our regulation by the
>>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>>> ( PRA ) are available from us on request.
>>>
>>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>>> under No.FC016201, Branch No.BR000036
>>>
>>> To comply with requirements imposed by the IRS, we inform you that any
>>> discussion of U.S. federal tax issues contained herein (including any
>>> attachments) was not intended or written to be used, and cannot be used by
>>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>>> Code or (ii) promoting, marketing or recommending any transaction or matter
>>> addressed herein to another party.
>>>
>>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is
>>> regulated by the Central Bank of Ireland and is a member of the Intesa
>>> Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg.
>>> No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock,
>>> IFSC, Dublin 1, Ireland.
>>>
>>
>

Re: [Quantlib-dev] Index fixings at end of month

[Luigi B. <lui...@gm...>]

Hello,
    I'm ok with coding it in InflationIndex as you did in your pull request.

Luigi

On Thu, Nov 13, 2014 at 2:26 PM, Francois Botha <ig...@gm...> wrote:

> Hi,
>
> I have an interpolated ZeroInflationIndex. My fixings are supposed to
> "fix" at the end of each month. So any interpolated value on the end of the
> month should be equal to the original fixing, i.e. no interpolation occurs.
> The fixings are applicable from the end of the month back towards the 1st
> of the same month.
>
> The current ZeroInflationIndex implementation assumes that fixings are on
> the 1st of the month and apply forward to the rest of the month, so lookups
> to values at the end of the month are slightly off for my use case.
>
> I can fix this by adding a suitable parameter, but I want to know whether
> I should include this in the ZeroInflationIndex class or higher up in the
> InflationIndex class. Besides ZeroInflationIndex, InterestRateIndex and its
> subclasses also derive from InflationIndex. I'm unsure whether this change
> would be applicable for those too.
>
> thanks
> Francois Botha
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

yes, please send an example (otherwise I could already take the one from
the excel you sent earlier ? or was that made up ?). In addtion I think I
should add a technical test like

for random input x
- y = direct(x) generates admissable values
- direct( inverse( y ) ) = y

for sabr, noarbsabr, zabr and svi. What do you think ?

Peter


On 17 November 2014 20:07, Ferdinando M. Ametrano <na...@am...>
wrote:

> Thank you Peter for the timely fix.
>
> One takeaway is to create a unit test to check for possible future
> regressions.
> Do you have a relevant dataset from some paper to suggest? If not, I could
> provide a snapshot of current euro caplets.
> On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <
> pao...@es...> wrote:
>
>>  Hi Peter,
>>
>> I tested your modifications and they work properly. The results are in
>> line with the ones obtained using QL 1.2.
>>
>> Anyway, the details (forward and time to expiry) are written in the excel
>> file attached in the previous email.
>>
>>
>>
>> time
>>
>> fwd
>>
>> 0.1342
>>
>> 1.1075%
>>
>> 0.3833
>>
>> 1.1025%
>>
>>
>>
>> Thank you very much for your help.
>>
>>
>>
>> Paolo
>>
>>
>>
>> *Paolo Mazzocchi*
>>
>> *Deloitte Consulting Srl*
>>
>> consulente di
>>
>> *FINANCIAL ENGINEERING - Banca IMI*
>>
>> Tel: 02-72615029  Int: 35029
>>
>> *pao...@es... <pao...@es...>*
>>
>>
>>
>> *From:* Peter Caspers [mailto:pca...@gm...]
>> *Sent:* Monday, November 17, 2014 7:00 PM
>> *To:* Ferdinando M. Ametrano
>> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
>> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>>
>>
>>
>> Hi Ferdinando,
>>
>> I pushed a fix here (effectively it should yield the same results as the
>> file attached earlier)
>>
>> https://github.com/lballabio/quantlib/pull/170
>>
>> As far as I remember the reason for the change in the transformation
>> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
>> time in the calibration. This is why I replaced the parabolas by truncated
>> parabolas with linear wings (such that the result is C^1).
>>
>> If you feel that your test case is still working better in 1.2, could you
>> please send some more details (forward, time to expiry), I'd be happy to
>> discuss again then.
>>
>>
>>
>> Best regards
>> Peter
>>
>>
>>
>> On 17 November 2014 13:25, Peter Caspers <pca...@gm...> wrote:
>>
>> Hi Ferdinando,
>>
>> one problem is the transformation function direct(...) which is buggy for
>> alpha and nu. Can you try the attached version instead and see if it works
>> better ?
>>
>> I'd like to have a closer look and try on more cases before I send a PR
>> though.
>>
>> Thanks
>>
>> Peter
>>
>>
>>
>> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
>> wrote:
>>
>> Hi Peter
>>
>>
>>
>> SABR implementation on the current trunk has a regression compared with
>> QuantLib 1.2.1
>>
>>
>>
>> While trying to calibrate problematic smiles as:
>>
>>
>>
>> strike
>>
>> 1.00%
>>
>> 1.13%
>>
>> 1.25%
>>
>> 1.38%
>>
>> 1.50%
>>
>> vol1
>>
>> 23.20%
>>
>> 20.25%
>>
>> 31.21%
>>
>> 39.02%
>>
>> 50.45%
>>
>> vol2
>>
>> 16.67%
>>
>> 20.20%
>>
>> 27.85%
>>
>> 32.79%
>>
>> 37.27%
>>
>>
>>
>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>
>>
>>
>> max error
>>
>> rms error
>>
>> end criteria
>>
>> alpha
>>
>> beta
>>
>> nu
>>
>> rho
>>
>> 1.79%
>>
>> 0.94%
>>
>>  StationaryPoint
>>
>> 0.58%
>>
>> 25.00%
>>
>> 346.03%
>>
>> 34.19%
>>
>> 0.65%
>>
>> 0.43%
>>
>> StationaryPoint
>>
>> 0.62%
>>
>> 25.00%
>>
>> 193.97%
>>
>> 63.66%
>>
>>
>>
>>
>>
>> the current trunk instead fails for the second smile with error
>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>
>>
>>
>> If one tries to just use the four leftmost volatilities to simplify the
>> problem, both calibrations fail with the same error. This leads me to
>> believe the problem is about the solver looking for a solution in the
>> negative nu region. If this is the case it could be solved having a
>> positive constraint for nu. Do you agree? Could you please look into it?
>>
>>
>>
>> Please find attached a spreadsheet reproducing the error. We might even
>> want to add a non regression test to the test suite.
>>
>>
>>
>> thank you for your help
>>
>>
>>
>> regards
>>
>> F
>>
>>
>>
>>
>>
>>
>> Prima di stampare, pensa all'ambiente ** Think about the environment
>> before printing
>>
>> ------------------------------
>>
>> Il presente messaggio, inclusi gli eventuali allegati, ha natura
>> aziendale e potrebbe contenere informazioni confidenziali e/o riservate.
>> Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il
>> mittente e di cancellarlo.
>> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
>> diffusione non autorizzata del contenuto di questo messaggio o di parte di
>> esso.
>> Pur essendo state assunte le dovute precauzioni per ridurre al minimo il
>> rischio di trasmissione di virus, si suggerisce di effettuare gli opportuni
>> controlli sui documenti allegati al presente messaggio. Non si assume
>> alcuna responsabilità per eventuali danni o perdite derivanti dalla
>> presenza di virus.
>>
>> Per lo svolgimento delle attività di investimento nel Regno Unito, la
>> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
>> limitata della Financial Conduct Authority ( FCA ) e della Prudential
>> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
>> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
>> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>>
>> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
>> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
>> & Galles sotto No.FC016201, Branch No.BR000036
>>
>> In osservanza dei requisito imposti dal Internal Revenue Service (Agenzia
>> delle Entrate degli Stati Uniti), qualunque discussione relativa a temi di
>> natura fiscale contenuta in questo messaggio o nei suoi allegati non e’
>> intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
>> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
>> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
>> sollecitare o raccomandare una operazione finanziaria o altra transazione
>> indirizzata ad un altro destinatario.
>>
>> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
>> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
>> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
>> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
>> Irlanda.
>>
>> ***
>>
>> ------------------------------
>>
>> This email (including any attachment) is a corporate message and may
>> contain confidential and/or privileged and/or proprietary information. If
>> you have received this email in error, please notify the sender
>> immediately, do not use or share it and destroy this email. Any
>> unauthorised use, copying or disclosure of the material in this email or of
>> parts hereof (including reliance thereon) is strictly forbidden.
>> We have taken precautions to minimize the risk of transmitting software
>> viruses but nevertheless advise you to carry out your own virus checks on
>> any attachment of this message. We accept no liability for loss or damage
>> caused by software viruses.
>>
>> For the conduct of investment business in the UK, the Company is
>> authorised by Banca d’Italia and subject to limited regulation in the UK by
>> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
>> Authority ( PRA ). Details about the extent of our regulation by the
>> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
>> ( PRA ) are available from us on request.
>>
>> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
>> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
>> under No.FC016201, Branch No.BR000036
>>
>> To comply with requirements imposed by the IRS, we inform you that any
>> discussion of U.S. federal tax issues contained herein (including any
>> attachments) was not intended or written to be used, and cannot be used by
>> you, for the purpose of (i) avoiding penalties under the Internal Revenue
>> Code or (ii) promoting, marketing or recommending any transaction or matter
>> addressed herein to another party.
>>
>> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is regulated
>> by the Central Bank of Ireland and is a member of the Intesa Sanpaolo
>> Group. It is registered in Ireland as company no.125216 – VAT Reg. No. IE
>> 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock, IFSC,
>> Dublin 1, Ireland.
>>
>

Re: [Quantlib-dev] FW: SABR regression

[Ferdinando M. A. <na...@am...>]

Thank you Peter for the timely fix.

One takeaway is to create a unit test to check for possible future
regressions.
Do you have a relevant dataset from some paper to suggest? If not, I could
provide a snapshot of current euro caplets.
On Nov 17, 2014 7:40 PM, "MAZZOCCHI PAOLO" <pao...@es...>
wrote:

>  Hi Peter,
>
> I tested your modifications and they work properly. The results are in
> line with the ones obtained using QL 1.2.
>
> Anyway, the details (forward and time to expiry) are written in the excel
> file attached in the previous email.
>
>
>
> time
>
> fwd
>
> 0.1342
>
> 1.1075%
>
> 0.3833
>
> 1.1025%
>
>
>
> Thank you very much for your help.
>
>
>
> Paolo
>
>
>
> *Paolo Mazzocchi*
>
> *Deloitte Consulting Srl*
>
> consulente di
>
> *FINANCIAL ENGINEERING - Banca IMI*
>
> Tel: 02-72615029  Int: 35029
>
> *pao...@es... <pao...@es...>*
>
>
>
> *From:* Peter Caspers [mailto:pca...@gm...]
> *Sent:* Monday, November 17, 2014 7:00 PM
> *To:* Ferdinando M. Ametrano
> *Cc:* maz...@li...; QuantLib Mailing Lists; maddalena zanzi
> *Subject:* Re: [Quantlib-dev] FW: SABR regression
>
>
>
> Hi Ferdinando,
>
> I pushed a fix here (effectively it should yield the same results as the
> file attached earlier)
>
> https://github.com/lballabio/quantlib/pull/170
>
> As far as I remember the reason for the change in the transformation
> function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
> time in the calibration. This is why I replaced the parabolas by truncated
> parabolas with linear wings (such that the result is C^1).
>
> If you feel that your test case is still working better in 1.2, could you
> please send some more details (forward, time to expiry), I'd be happy to
> discuss again then.
>
>
>
> Best regards
> Peter
>
>
>
> On 17 November 2014 13:25, Peter Caspers <pca...@gm...> wrote:
>
> Hi Ferdinando,
>
> one problem is the transformation function direct(...) which is buggy for
> alpha and nu. Can you try the attached version instead and see if it works
> better ?
>
> I'd like to have a closer look and try on more cases before I send a PR
> though.
>
> Thanks
>
> Peter
>
>
>
> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
> wrote:
>
> Hi Peter
>
>
>
> SABR implementation on the current trunk has a regression compared with
> QuantLib 1.2.1
>
>
>
> While trying to calibrate problematic smiles as:
>
>
>
> strike
>
> 1.00%
>
> 1.13%
>
> 1.25%
>
> 1.38%
>
> 1.50%
>
> vol1
>
> 23.20%
>
> 20.25%
>
> 31.21%
>
> 39.02%
>
> 50.45%
>
> vol2
>
> 16.67%
>
> 20.20%
>
> 27.85%
>
> 32.79%
>
> 37.27%
>
>
>
> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>
>
>
> max error
>
> rms error
>
> end criteria
>
> alpha
>
> beta
>
> nu
>
> rho
>
> 1.79%
>
> 0.94%
>
>  StationaryPoint
>
> 0.58%
>
> 25.00%
>
> 346.03%
>
> 34.19%
>
> 0.65%
>
> 0.43%
>
> StationaryPoint
>
> 0.62%
>
> 25.00%
>
> 193.97%
>
> 63.66%
>
>
>
>
>
> the current trunk instead fails for the second smile with error
> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>
>
>
> If one tries to just use the four leftmost volatilities to simplify the
> problem, both calibrations fail with the same error. This leads me to
> believe the problem is about the solver looking for a solution in the
> negative nu region. If this is the case it could be solved having a
> positive constraint for nu. Do you agree? Could you please look into it?
>
>
>
> Please find attached a spreadsheet reproducing the error. We might even
> want to add a non regression test to the test suite.
>
>
>
> thank you for your help
>
>
>
> regards
>
> F
>
>
>
>
>
>
> Prima di stampare, pensa all'ambiente ** Think about the environment
> before printing
>
> ------------------------------
>
> Il presente messaggio, inclusi gli eventuali allegati, ha natura aziendale
> e potrebbe contenere informazioni confidenziali e/o riservate. Chiunque lo
> ricevesse per errore, è pregato di avvisare tempestivamente il mittente e
> di cancellarlo.
> E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o
> diffusione non autorizzata del contenuto di questo messaggio o di parte di
> esso.
> Pur essendo state assunte le dovute precauzioni per ridurre al minimo il
> rischio di trasmissione di virus, si suggerisce di effettuare gli opportuni
> controlli sui documenti allegati al presente messaggio. Non si assume
> alcuna responsabilità per eventuali danni o perdite derivanti dalla
> presenza di virus.
>
> Per lo svolgimento delle attività di investimento nel Regno Unito, la
> società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza
> limitata della Financial Conduct Authority ( FCA ) e della Prudential
> Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di
> vigilanza della Financial Conduct Authority ( FCA ) e della Prudential
> Regulation Authority ( PRA ) sono a disposizione previa richiesta.
>
> Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di
> Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra
> & Galles sotto No.FC016201, Branch No.BR000036
>
> In osservanza dei requisito imposti dal Internal Revenue Service (Agenzia
> delle Entrate degli Stati Uniti), qualunque discussione relativa a temi di
> natura fiscale contenuta in questo messaggio o nei suoi allegati non e’
> intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere
> utilizata per (i) evitare l’imposizione di gravami fiscali secondo il
> codice tributario vigente negli Stati Uniti o (ii) per promuovere,
> sollecitare o raccomandare una operazione finanziaria o altra transazione
> indirizzata ad un altro destinatario.
>
> Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è
> regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario
> Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 –
> IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1,
> Irlanda.
>
> ***
>
> ------------------------------
>
> This email (including any attachment) is a corporate message and may
> contain confidential and/or privileged and/or proprietary information. If
> you have received this email in error, please notify the sender
> immediately, do not use or share it and destroy this email. Any
> unauthorised use, copying or disclosure of the material in this email or of
> parts hereof (including reliance thereon) is strictly forbidden.
> We have taken precautions to minimize the risk of transmitting software
> viruses but nevertheless advise you to carry out your own virus checks on
> any attachment of this message. We accept no liability for loss or damage
> caused by software viruses.
>
> For the conduct of investment business in the UK, the Company is
> authorised by Banca d’Italia and subject to limited regulation in the UK by
> the Financial Conduct Authority ( FCA ) and the Prudential Regulation
> Authority ( PRA ). Details about the extent of our regulation by the
> Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority
> ( PRA ) are available from us on request.
>
> In the UK Intesa Sanpaolo S.p.A. operates through its London Branch,
> located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales
> under No.FC016201, Branch No.BR000036
>
> To comply with requirements imposed by the IRS, we inform you that any
> discussion of U.S. federal tax issues contained herein (including any
> attachments) was not intended or written to be used, and cannot be used by
> you, for the purpose of (i) avoiding penalties under the Internal Revenue
> Code or (ii) promoting, marketing or recommending any transaction or matter
> addressed herein to another party.
>
> In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is regulated
> by the Central Bank of Ireland and is a member of the Intesa Sanpaolo
> Group. It is registered in Ireland as company no.125216 – VAT Reg. No. IE
> 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock, IFSC,
> Dublin 1, Ireland.
>

Re: [Quantlib-dev] QuantLib + boost 1.55

[auser <ade...@gm...>]

Hey Luigi,

Thanks for your message this indeed solves the issue.
One small correction: stdlib instead of stlib. It is also in one of your SO
posts.




--
View this message in context: http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16048.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] FW: SABR regression

[MAZZOCCHI P. <pao...@es...>]

Hi Peter,
I tested your modifications and they work properly. The results are in line with the ones obtained using QL 1.2.
Anyway, the details (forward and time to expiry) are written in the excel file attached in the previous email.

time

fwd

0.1342

1.1075%

0.3833

1.1025%


Thank you very much for your help.

Paolo

Paolo Mazzocchi
Deloitte Consulting Srl
consulente di
FINANCIAL ENGINEERING - Banca IMI
Tel: 02-72615029  Int: 35029
pao...@es...<mailto:pao...@es...>

From: Peter Caspers [mailto:pca...@gm...]
Sent: Monday, November 17, 2014 7:00 PM
To: Ferdinando M. Ametrano
Cc: maz...@li...; QuantLib Mailing Lists; maddalena zanzi
Subject: Re: [Quantlib-dev] FW: SABR regression

Hi Ferdinando,
I pushed a fix here (effectively it should yield the same results as the file attached earlier)

https://github.com/lballabio/quantlib/pull/170
As far as I remember the reason for the change in the transformation function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to time in the calibration. This is why I replaced the parabolas by truncated parabolas with linear wings (such that the result is C^1).
If you feel that your test case is still working better in 1.2, could you please send some more details (forward, time to expiry), I'd be happy to discuss again then.

Best regards
Peter

On 17 November 2014 13:25, Peter Caspers <pca...@gm...<mailto:pca...@gm...>> wrote:
Hi Ferdinando,
one problem is the transformation function direct(...) which is buggy for alpha and nu. Can you try the attached version instead and see if it works better ?
I'd like to have a closer look and try on more cases before I send a PR though.

Thanks
Peter

On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...<mailto:na...@am...>> wrote:
Hi Peter

SABR implementation on the current trunk has a regression compared with QuantLib 1.2.1

While trying to calibrate problematic smiles as:

strike

1.00%

1.13%

1.25%

1.38%

1.50%

vol1

23.20%

20.25%

31.21%

39.02%

50.45%

vol2

16.67%

20.20%

27.85%

32.79%

37.27%


1.2.1 was able to offer these (non-optimal but decent) solutions:

max error

rms error

end criteria

alpha

beta

nu

rho

1.79%

0.94%

 StationaryPoint

0.58%

25.00%

346.03%

34.19%

0.65%

0.43%

StationaryPoint

0.62%

25.00%

193.97%

63.66%



the current trunk instead fails for the second smile with error "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".

If one tries to just use the four leftmost volatilities to simplify the problem, both calibrations fail with the same error. This leads me to believe the problem is about the solver looking for a solution in the negative nu region. If this is the case it could be solved having a positive constraint for nu. Do you agree? Could you please look into it?

Please find attached a spreadsheet reproducing the error. We might even want to add a non regression test to the test suite.

thank you for your help

regards
F




Prima di stampare, pensa all'ambiente ** Think about the environment before printing

________________________________

Il presente messaggio, inclusi gli eventuali allegati, ha natura aziendale e potrebbe contenere informazioni confidenziali e/o riservate. Chiunque lo ricevesse per errore, è pregato di avvisare tempestivamente il mittente e di cancellarlo.
E’ strettamente vietata qualsiasi forma di utilizzo, riproduzione o diffusione non autorizzata del contenuto di questo messaggio o di parte di esso.
Pur essendo state assunte le dovute precauzioni per ridurre al minimo il rischio di trasmissione di virus, si suggerisce di effettuare gli opportuni controlli sui documenti allegati al presente messaggio. Non si assume alcuna responsabilità per eventuali danni o perdite derivanti dalla presenza di virus.

Per lo svolgimento delle attività di investimento nel Regno Unito, la società è autorizzata da Banca d'Italia ed è soggetta alla vigilanza limitata della Financial Conduct Authority ( FCA ) e della Prudential Regulation Authority ( PRA ) . Maggiori informazioni in merito ai poteri di vigilanza della Financial Conduct Authority ( FCA ) e della Prudential Regulation Authority ( PRA ) sono a disposizione previa richiesta.

Nel Regno Unito Intesa Sanpaolo S.p.A. opera attraverso la filiale di Londra, sita in 90 Queen Street, London EC4N 1SA, registrata in Inghilterra & Galles sotto No.FC016201, Branch No.BR000036

In osservanza dei requisito imposti dal Internal Revenue Service (Agenzia delle Entrate degli Stati Uniti), qualunque discussione relativa a temi di natura fiscale contenuta in questo messaggio o nei suoi allegati non e’ intesa ne’ e’ stata scritta per essere utilizzata, ne’ puo’ essere utilizata per (i) evitare l’imposizione di gravami fiscali secondo il codice tributario vigente negli Stati Uniti o (ii) per promuovere, sollecitare o raccomandare una operazione finanziaria o altra transazione indirizzata ad un altro destinatario.

Nella Repubblica d’Irlanda, Intesa Sanpaolo Bank Ireland plc è regolamentata dalla Banca Centrale d’Irlanda ed è parte del Gruppo Bancario Intesa Sanpaolo S.p.A. Registrata in Irlanda come società numero 125216 – IVA Reg. IE4817418C IE, sita in, KBC House, 4 George Dock, IFSC, Dublino 1, Irlanda.

***

________________________________

This email (including any attachment) is a corporate message and may contain confidential and/or privileged and/or proprietary information. If you have received this email in error, please notify the sender immediately, do not use or share it and destroy this email. Any unauthorised use, copying or disclosure of the material in this email or of parts hereof (including reliance thereon) is strictly forbidden.
We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment of this message. We accept no liability for loss or damage caused by software viruses.

For the conduct of investment business in the UK, the Company is authorised by Banca d’Italia and subject to limited regulation in the UK by the Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority ( PRA ). Details about the extent of our regulation by the Financial Conduct Authority ( FCA ) and the Prudential Regulation Authority ( PRA ) are available from us on request.

In the UK Intesa Sanpaolo S.p.A. operates through its London Branch, located at 90 Queen Street, London EC4N 1SA. Registered in England & Wales under No.FC016201, Branch No.BR000036

To comply with requirements imposed by the IRS, we inform you that any discussion of U.S. federal tax issues contained herein (including any attachments) was not intended or written to be used, and cannot be used by you, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending any transaction or matter addressed herein to another party.

In the Republic of Ireland, Intesa Sanpaolo Bank Ireland plc is regulated by the Central Bank of Ireland and is a member of the Intesa Sanpaolo Group. It is registered in Ireland as company no.125216 – VAT Reg. No. IE 4817418C and located at, 3rd Floor, KBC House, 4 George’s Dock, IFSC, Dublin 1, Ireland.

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

Hi Ferdinando,

I pushed a fix here (effectively it should yield the same results as the
file attached earlier)

https://github.com/lballabio/quantlib/pull/170

As far as I remember the reason for the change in the transformation
function (for 1.3 or 1.4 ?) were nan / inf values occuring from time to
time in the calibration. This is why I replaced the parabolas by truncated
parabolas with linear wings (such that the result is C^1).

If you feel that your test case is still working better in 1.2, could you
please send some more details (forward, time to expiry), I'd be happy to
discuss again then.

Best regards
Peter

On 17 November 2014 13:25, Peter Caspers <pca...@gm...> wrote:

> Hi Ferdinando,
>
> one problem is the transformation function direct(...) which is buggy for
> alpha and nu. Can you try the attached version instead and see if it works
> better ?
>
> I'd like to have a closer look and try on more cases before I send a PR
> though.
>
> Thanks
> Peter
>
> On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
> wrote:
>
>> Hi Peter
>>
>> SABR implementation on the current trunk has a regression compared with
>> QuantLib 1.2.1
>>
>> While trying to calibrate problematic smiles as:
>>
>> strike1.00%1.13%1.25%1.38%1.50%vol123.20%20.25%31.21%39.02%50.45%vol2
>> 16.67%20.20%27.85%32.79%37.27%
>>
>> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>>
>> max errorrms errorend criteriaalphabetanurho1.79%0.94% StationaryPoint
>> 0.58%25.00%346.03%34.19%0.65%0.43% StationaryPoint0.62%25.00%193.97%
>> 63.66%
>>
>>
>> the current trunk instead fails for the second smile with error
>> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>>
>> If one tries to just use the four leftmost volatilities to simplify the
>> problem, both calibrations fail with the same error. This leads me to
>> believe the problem is about the solver looking for a solution in the
>> negative nu region. If this is the case it could be solved having a
>> positive constraint for nu. Do you agree? Could you please look into it?
>>
>> Please find attached a spreadsheet reproducing the error. We might even
>> want to add a non regression test to the test suite.
>>
>> thank you for your help
>>
>> regards
>> F
>>
>
>

Re: [Quantlib-dev] QuantLib + boost 1.55

[Luigi B. <lui...@gm...>]

This was suggested earlier in the thread. Does it fix the issue?

--------------------
To build the library on Mac OS X 10.9, the QuantLib library must be linked
against libstdc++. To do so, set the environment flags `CXXFLAGS` and
`LDFLAGS`
to `-stlib=libstdc++ -mmacosx-version-min=10.6` before compiling from
source.


On Mon, Nov 17, 2014 at 2:51 AM, auser <ade...@gm...> wrote:

> Can you please help us with how to solve the issue?
>
>
>
>
> --
> View this message in context:
> http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16038.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>



-- 
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

Re: [Quantlib-dev] FW: SABR regression

[Peter C. <pca...@gm...>]

Hi Ferdinando,

one problem is the transformation function direct(...) which is buggy for
alpha and nu. Can you try the attached version instead and see if it works
better ?

I'd like to have a closer look and try on more cases before I send a PR
though.

Thanks
Peter

On 17 November 2014 12:06, Ferdinando M. Ametrano <na...@am...>
wrote:

> Hi Peter
>
> SABR implementation on the current trunk has a regression compared with
> QuantLib 1.2.1
>
> While trying to calibrate problematic smiles as:
>
> strike1.00%1.13%1.25%1.38%1.50%vol123.20%20.25%31.21%39.02%50.45%vol2
> 16.67%20.20%27.85%32.79%37.27%
>
> 1.2.1 was able to offer these (non-optimal but decent) solutions:
>
> max errorrms errorend criteriaalphabetanurho1.79%0.94% StationaryPoint
> 0.58%25.00%346.03%34.19%0.65%0.43% StationaryPoint0.62%25.00%193.97%63.66%
>
>
> the current trunk instead fails for the second smile with error
> "qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".
>
> If one tries to just use the four leftmost volatilities to simplify the
> problem, both calibrations fail with the same error. This leads me to
> believe the problem is about the solver looking for a solution in the
> negative nu region. If this is the case it could be solved having a
> positive constraint for nu. Do you agree? Could you please look into it?
>
> Please find attached a spreadsheet reproducing the error. We might even
> want to add a non regression test to the test suite.
>
> thank you for your help
>
> regards
> F
>

[Quantlib-dev] Fwd: FW: SABR regression

[Ferdinando M. A. <na...@am...>]

Hi Peter

SABR implementation on the current trunk has a regression compared with
QuantLib 1.2.1

While trying to calibrate problematic smiles as:

strike1.00%1.13%1.25%1.38%1.50%vol123.20%20.25%31.21%39.02%50.45%vol216.67%
20.20%27.85%32.79%37.27%

1.2.1 was able to offer these (non-optimal but decent) solutions:

max errorrms errorend criteriaalphabetanurho1.79%0.94% StationaryPoint0.58%
25.00%346.03%34.19%0.65%0.43% StationaryPoint0.62%25.00%193.97%63.66%


the current trunk instead fails for the second smile with error
"qlSABRInterpolationAlpha - nu must be non negative: -124.897 not allowed".

If one tries to just use the four leftmost volatilities to simplify the
problem, both calibrations fail with the same error. This leads me to
believe the problem is about the solver looking for a solution in the
negative nu region. If this is the case it could be solved having a
positive constraint for nu. Do you agree? Could you please look into it?

Please find attached a spreadsheet reproducing the error. We might even
want to add a non regression test to the test suite.

thank you for your help

regards
F

[Quantlib-dev] QuantLib 1.4.1 released

[Luigi B. <lui...@gm...>]

QuantLib is a cross-platform, free/open-source quantitative finance C++
library for modeling, pricing, trading, and risk management in real-life.

Version 1.4.1 has been released and is available for download at <
http://quantlib.org/download.shtml>.

QuantLib 1.4.1 is a compatibility release. It fixes a number of compilation
errors that surfaced when using QuantLib 1.4 with Clang 3.5 and Boost 1.57.
Thanks to Tim Smith for the heads-up.

If you are not using Clang, you don't need to upgrade from QuantLib 1.4 to
1.4.1.

Please log any problems you have with this release in the SourceForge bug
tracker at <http://sourceforge.net/tracker/?group_id=12740&atid=112740>
specifying that you're using QuantLib 1.4.1.

    The QuantLib group

Re: [Quantlib-dev] QuantLib + boost 1.55

[auser <ade...@gm...>]

Can you please help us with how to solve the issue?




--
View this message in context: http://quantlib.10058.n7.nabble.com/QuantLib-boost-1-55-tp14715p16038.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] 答复: 答复: Grids shift trick to improve the convergence speed PDE method

[Peter C. <pca...@gm...>]

you are right concerning the smoothed payoff. Still I wonder if it
wouldn't be better to move the smoothing to the Payoff, because in
most cases there will be a closed form solution for the smoothed
payoff. The numerical integration (Simpson), now always used, could
stay the default implementation, overwritten by closed form
expressions for payoffs where possible. I didn't try though, so this
might not be really better than using Simpson with respect to speed
and / or accuracy. I guess it isn't, otherwise Klaus and his team
would have done so :-)
Peter

On 16 November 2014 06:30, cheng li <scr...@gm...> wrote:
> Hi Peter,
>
> Thanks for your comment. It is really helpful.
>
> 1. Using std stuff will shorten the codes and make the codesclearer. I'll take that advice and change my implementation accordingly.
>
> 2. Smoothed payoff
>
> As diving into the codes deeper, I find that for FdBlackScholesVanillaEngine the smoothing technical has already been taken in. Please see the class FdmInnerValueCalculator. It is responsible for calculating average payoff value through its methd avgInnerValue. So it seems that the actual comparison I have done is that : 'Grids Shift + Payoff Smoothing + Damping'  v.s.  'Payoff Smoothing + Damping '. I apologized for the missing point.
>
> Anyway as the experiment shows Payoff Smooting seems is less effective than Grids Shift ( or it may say that Payoff Smoothing and Grids Shift should work together. I haven't done an experiment with Grids shift only)
>
> 3. To move Grids shift stuff from pricing engine to payoff.
>
> Yes, I agree. This will locate the trick to where it really matters. Grids shift is working for payoff functions who have some discontinuity. So it is a payoff specific treatment. To make it engine specifc has 2 shortcome: a. it will apply to some other options who is not related to discountinuity(although it seems not hurt currently) b. it miss the chance to apply this trick to other pricing engine who also deal with payoff with discontinuity, e.g. FdBlackScholesBarrierEngine, FDEuropeanEngine)
>
> I'll think about how to adjust my implementation. Any advice is welcome.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Peter Caspers [mailto:pca...@gm...]
> 发送时间: 2014年11月15日 3:34
> 收件人: cheng li
> 抄送: Klaus Spanderen; QuantLib Mailing Lists
> 主题: Re: [Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method
>
> This looks great. Some mundane comments:
>
> - requireCPoint and shiftLocation are somewhat contracting requirements, so we should forbid both being true by a QL_REQUIRE
> - the loop in L92 could easily be replaced by a simple
> lower_bound(...) - call to get (i+1), which does not help much in terms of performance, but is nicer code
> - cPoint is already ensured to be in [start, end], so i can not be = locations_size(), the check is not required I think. cPoint may be = start however, in which case i+1 = 0, in this case we should increase i by 1, the remaining code then works as desired.
>
> Also I think that this kind of adjustment - another example would possibly be the smoothed payoff function described just in the section just before the one you refer to (does that improve the vanilla case btw ?) - should maybe be triggered from the Payoff, i.e. via optionally implemented functions in classes derived from Payoff like
>
> void adaptGrid( ... )        // given a fd grid, return a modification
> (with same start, end, #points) adapted to the payoff Real fdValue( ... , Real)  // return a payoff value smoothed w.r.t. a given fd grid
>
> Just a spontaneous idea, I don't know.
>
> Peter
>
>
> On 14 November 2014 14:17, cheng li <scr...@gm...> wrote:
>> Hi Spanderen,
>>
>> The numerical result says there is no much difference between these 2
>> methods for vanilla option:
>>
>> The parameters are same as my previous example
>>
>> Grids   Shift Grids + Damping   Damping
>> 10      4.049015807        4.023573966
>> 20      3.888731876     3.883259801
>> 30      3.859347301     3.860949207
>> 40      3.853164351     3.853494439
>> 50      3.850117743     3.850127399
>> 60      3.848403455     3.848320323
>> 70      3.847346072     3.847233176
>> 80      3.846453732     3.846532679
>> 90      3.846028584     3.84605574
>> 100     3.845716741     3.845717576
>> 110     3.845481428     3.845467956
>> 120     3.845299598     3.845277305
>> 130     3.845111453     3.845129343
>> 140     3.845005422     3.845012225
>> 150     3.844918509     3.84491863
>> 160     3.844846402     3.844841907
>> 170     3.844785935     3.844778105
>> 180     3.844717978     3.844724605
>> 190     3.844676773     3.844679439
>> 200     3.844641179     3.844641171
>> 210     3.844307792     3.844307792
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Cheng Li [mailto:scr...@gm...]
>> 发送时间: 2014年11月14日 20:09
>> 收件人: 'Klaus Spanderen'; qua...@li...
>> 主题: 答复: [Quantlib-dev] Grids shift trick to improve the convergence
>> speed PDE method
>>
>> Hi Spanderen,
>>
>> Let me do one for us. I'll come back to you when it is finished. IMO I
>> think the convergence speed won't improve as much as the case for
>> digital since there is no discontinuity in plain vanilla payoff.
>>
>> BTW, I agree with you that this will change the default behavior if
>> using my implementation. That is the reason I sent this all the
>> developers to see other's opinion before raise a pull request in github.
>>
>> Regards,
>> Cheng
>>
>> -----邮件原件-----
>> 发件人: Klaus Spanderen [mailto:kl...@sp...]
>> 发送时间: 2014年11月14日 14:42
>> 收件人: qua...@li...
>> 主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence
>> speed PDE method
>>
>> Hi
>>
>> cool!
>>
>> The results are looking promising. Do you get a similar improvement if
>> you apply the shift trick to plain vanilla option.
>>
>> The only thing we might consider is that we change behavior if the
>> shift becomes the default.
>>
>> regards
>> Klaus
>>
>> On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
>>> Hi Team,
>>>
>>>
>>>
>>> Current I am in an effort to improve the convergence speed of
>>> FdBlackScholesVanillaEngine to digital option. The background is as
>> follows:
>>>
>>>
>>>
>>> For digital option there is some discontinuity in the initial condition.
>>> Such discontinuity will cause the straight Crank-Nicolson method to
>>> show severe odd-even effect. In current implementation, the pricing
>>> engine will use several damping steps to suppress some effect.
>>> However as claimed in Interest Rate Modeling. Section 2.5 p60 in V1
>>> by Anderson and Piterbarg, Damping steps is not adequate for such task.
>>> Referencing to Tavella and Randall's book, they suggest to shift the
>>> grids to let the discontinuity lies exactly half way between 2 grids.
>>> They claimed that this will greatly improve the convergence.
>>>
>>>
>>>
>>> I have completed such experimental implementation in QuantLib.
>>> Besides I do a comparison between "Grids Shift + Damping" and "Damping"
>>> methods. The result is promising. The convergence speed is greatly
>>> improved and is consistent with what Anderson and Piterbarg claimed.
>>> The result can be referred from the attached Shift_experiment.xlsx file.
>>>
>>>
>>>
>>> To replicate my result, you can replacing the original files in
>>> ql\methods\finitedifferences\meshers with the files I attached
>>> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the
>>> test program testPDEScheme.cpp
>>>
>>>
>>>
>>> The results is based on "Grids shift + 2 damping steps". Also you can
>>> run the test program without replacing the mesher file to see what is
>>> result of
>>> "2 damping steps". Besides I also run through the QuantLIb test suite.
>>> This change won't break any existing test case.
>>>
>>>
>>>
>>> Is anyone have some interest to have a look at this? I'd like to
>>> create a pull request for this change if no one is against it.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Cheng
>>
>>
>> ----------------------------------------------------------------------
>> ------
>> --
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.
>> clktrk _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>>
>> ----------------------------------------------------------------------
>> -------- Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.
>> clktrk _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] 答复: 答复: Grids shift trick to improve the convergence speed PDE method

[cheng l. <scr...@gm...>]

Hi Peter,

Thanks for your comment. It is really helpful.

1. Using std stuff will shorten the codes and make the codesclearer. I'll take that advice and change my implementation accordingly.

2. Smoothed payoff

As diving into the codes deeper, I find that for FdBlackScholesVanillaEngine the smoothing technical has already been taken in. Please see the class FdmInnerValueCalculator. It is responsible for calculating average payoff value through its methd avgInnerValue. So it seems that the actual comparison I have done is that : 'Grids Shift + Payoff Smoothing + Damping'  v.s.  'Payoff Smoothing + Damping '. I apologized for the missing point.

Anyway as the experiment shows Payoff Smooting seems is less effective than Grids Shift ( or it may say that Payoff Smoothing and Grids Shift should work together. I haven't done an experiment with Grids shift only) 

3. To move Grids shift stuff from pricing engine to payoff.

Yes, I agree. This will locate the trick to where it really matters. Grids shift is working for payoff functions who have some discontinuity. So it is a payoff specific treatment. To make it engine specifc has 2 shortcome: a. it will apply to some other options who is not related to discountinuity(although it seems not hurt currently) b. it miss the chance to apply this trick to other pricing engine who also deal with payoff with discontinuity, e.g. FdBlackScholesBarrierEngine, FDEuropeanEngine)

I'll think about how to adjust my implementation. Any advice is welcome.

Regards,
Cheng

-----邮件原件-----
发件人: Peter Caspers [mailto:pca...@gm...] 
发送时间: 2014年11月15日 3:34
收件人: cheng li
抄送: Klaus Spanderen; QuantLib Mailing Lists
主题: Re: [Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method

This looks great. Some mundane comments:

- requireCPoint and shiftLocation are somewhat contracting requirements, so we should forbid both being true by a QL_REQUIRE
- the loop in L92 could easily be replaced by a simple
lower_bound(...) - call to get (i+1), which does not help much in terms of performance, but is nicer code
- cPoint is already ensured to be in [start, end], so i can not be = locations_size(), the check is not required I think. cPoint may be = start however, in which case i+1 = 0, in this case we should increase i by 1, the remaining code then works as desired.

Also I think that this kind of adjustment - another example would possibly be the smoothed payoff function described just in the section just before the one you refer to (does that improve the vanilla case btw ?) - should maybe be triggered from the Payoff, i.e. via optionally implemented functions in classes derived from Payoff like

void adaptGrid( ... )        // given a fd grid, return a modification
(with same start, end, #points) adapted to the payoff Real fdValue( ... , Real)  // return a payoff value smoothed w.r.t. a given fd grid

Just a spontaneous idea, I don't know.

Peter


On 14 November 2014 14:17, cheng li <scr...@gm...> wrote:
> Hi Spanderen,
>
> The numerical result says there is no much difference between these 2 
> methods for vanilla option:
>
> The parameters are same as my previous example
>
> Grids   Shift Grids + Damping   Damping
> 10      4.049015807        4.023573966
> 20      3.888731876     3.883259801
> 30      3.859347301     3.860949207
> 40      3.853164351     3.853494439
> 50      3.850117743     3.850127399
> 60      3.848403455     3.848320323
> 70      3.847346072     3.847233176
> 80      3.846453732     3.846532679
> 90      3.846028584     3.84605574
> 100     3.845716741     3.845717576
> 110     3.845481428     3.845467956
> 120     3.845299598     3.845277305
> 130     3.845111453     3.845129343
> 140     3.845005422     3.845012225
> 150     3.844918509     3.84491863
> 160     3.844846402     3.844841907
> 170     3.844785935     3.844778105
> 180     3.844717978     3.844724605
> 190     3.844676773     3.844679439
> 200     3.844641179     3.844641171
> 210     3.844307792     3.844307792
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Cheng Li [mailto:scr...@gm...]
> 发送时间: 2014年11月14日 20:09
> 收件人: 'Klaus Spanderen'; qua...@li...
> 主题: 答复: [Quantlib-dev] Grids shift trick to improve the convergence 
> speed PDE method
>
> Hi Spanderen,
>
> Let me do one for us. I'll come back to you when it is finished. IMO I 
> think the convergence speed won't improve as much as the case for 
> digital since there is no discontinuity in plain vanilla payoff.
>
> BTW, I agree with you that this will change the default behavior if 
> using my implementation. That is the reason I sent this all the 
> developers to see other's opinion before raise a pull request in github.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Klaus Spanderen [mailto:kl...@sp...]
> 发送时间: 2014年11月14日 14:42
> 收件人: qua...@li...
> 主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence 
> speed PDE method
>
> Hi
>
> cool!
>
> The results are looking promising. Do you get a similar improvement if 
> you apply the shift trick to plain vanilla option.
>
> The only thing we might consider is that we change behavior if the 
> shift becomes the default.
>
> regards
> Klaus
>
> On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
>> Hi Team,
>>
>>
>>
>> Current I am in an effort to improve the convergence speed of 
>> FdBlackScholesVanillaEngine to digital option. The background is as
> follows:
>>
>>
>>
>> For digital option there is some discontinuity in the initial condition.
>> Such discontinuity will cause the straight Crank-Nicolson method to 
>> show severe odd-even effect. In current implementation, the pricing 
>> engine will use several damping steps to suppress some effect. 
>> However as claimed in Interest Rate Modeling. Section 2.5 p60 in V1 
>> by Anderson and Piterbarg, Damping steps is not adequate for such task.
>> Referencing to Tavella and Randall's book, they suggest to shift the 
>> grids to let the discontinuity lies exactly half way between 2 grids.
>> They claimed that this will greatly improve the convergence.
>>
>>
>>
>> I have completed such experimental implementation in QuantLib. 
>> Besides I do a comparison between "Grids Shift + Damping" and "Damping"
>> methods. The result is promising. The convergence speed is greatly 
>> improved and is consistent with what Anderson and Piterbarg claimed.
>> The result can be referred from the attached Shift_experiment.xlsx file.
>>
>>
>>
>> To replicate my result, you can replacing the original files in 
>> ql\methods\finitedifferences\meshers with the files I attached 
>> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the 
>> test program testPDEScheme.cpp
>>
>>
>>
>> The results is based on "Grids shift + 2 damping steps". Also you can 
>> run the test program without replacing the mesher file to see what is 
>> result of
>> "2 damping steps". Besides I also run through the QuantLIb test suite.
>> This change won't break any existing test case.
>>
>>
>>
>> Is anyone have some interest to have a look at this? I'd like to 
>> create a pull request for this change if no one is against it.
>>
>>
>>
>> Regards,
>>
>> Cheng
>
>
> ----------------------------------------------------------------------
> ------
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.
> clktrk _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
> ----------------------------------------------------------------------
> -------- Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.
> clktrk _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method

[Peter C. <pca...@gm...>]

This looks great. Some mundane comments:

- requireCPoint and shiftLocation are somewhat contracting
requirements, so we should forbid both being true by a QL_REQUIRE
- the loop in L92 could easily be replaced by a simple
lower_bound(...) - call to get (i+1), which does not help much in
terms of performance, but is nicer code
- cPoint is already ensured to be in [start, end], so i can not be =
locations_size(), the check is not required I think. cPoint may be =
start however, in which case i+1 = 0, in this case we should increase
i by 1, the remaining code then works as desired.

Also I think that this kind of adjustment - another example would
possibly be the smoothed payoff function described just in the section
just before the one you refer to (does that improve the vanilla case
btw ?) - should maybe be triggered from the Payoff, i.e. via
optionally implemented functions in classes derived from Payoff like

void adaptGrid( ... )        // given a fd grid, return a modification
(with same start, end, #points) adapted to the payoff
Real fdValue( ... , Real)  // return a payoff value smoothed w.r.t. a
given fd grid

Just a spontaneous idea, I don't know.

Peter


On 14 November 2014 14:17, cheng li <scr...@gm...> wrote:
> Hi Spanderen,
>
> The numerical result says there is no much difference between these 2
> methods for vanilla option:
>
> The parameters are same as my previous example
>
> Grids   Shift Grids + Damping   Damping
> 10      4.049015807        4.023573966
> 20      3.888731876     3.883259801
> 30      3.859347301     3.860949207
> 40      3.853164351     3.853494439
> 50      3.850117743     3.850127399
> 60      3.848403455     3.848320323
> 70      3.847346072     3.847233176
> 80      3.846453732     3.846532679
> 90      3.846028584     3.84605574
> 100     3.845716741     3.845717576
> 110     3.845481428     3.845467956
> 120     3.845299598     3.845277305
> 130     3.845111453     3.845129343
> 140     3.845005422     3.845012225
> 150     3.844918509     3.84491863
> 160     3.844846402     3.844841907
> 170     3.844785935     3.844778105
> 180     3.844717978     3.844724605
> 190     3.844676773     3.844679439
> 200     3.844641179     3.844641171
> 210     3.844307792     3.844307792
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Cheng Li [mailto:scr...@gm...]
> 发送时间: 2014年11月14日 20:09
> 收件人: 'Klaus Spanderen'; qua...@li...
> 主题: 答复: [Quantlib-dev] Grids shift trick to improve the convergence
> speed PDE method
>
> Hi Spanderen,
>
> Let me do one for us. I'll come back to you when it is finished. IMO I think
> the convergence speed won't improve as much as the case for digital since
> there is no discontinuity in plain vanilla payoff.
>
> BTW, I agree with you that this will change the default behavior if using my
> implementation. That is the reason I sent this all the developers to see
> other's opinion before raise a pull request in github.
>
> Regards,
> Cheng
>
> -----邮件原件-----
> 发件人: Klaus Spanderen [mailto:kl...@sp...]
> 发送时间: 2014年11月14日 14:42
> 收件人: qua...@li...
> 主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence speed
> PDE method
>
> Hi
>
> cool!
>
> The results are looking promising. Do you get a similar improvement if you
> apply the shift trick to plain vanilla option.
>
> The only thing we might consider is that we change behavior if the shift
> becomes the default.
>
> regards
> Klaus
>
> On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
>> Hi Team,
>>
>>
>>
>> Current I am in an effort to improve the convergence speed of
>> FdBlackScholesVanillaEngine to digital option. The background is as
> follows:
>>
>>
>>
>> For digital option there is some discontinuity in the initial condition.
>> Such discontinuity will cause the straight Crank-Nicolson method to
>> show severe odd-even effect. In current implementation, the pricing
>> engine will use several damping steps to suppress some effect. However
>> as claimed in Interest Rate Modeling. Section 2.5 p60 in V1 by
>> Anderson and Piterbarg, Damping steps is not adequate for such task.
>> Referencing to Tavella and Randall's book, they suggest to shift the
>> grids to let the discontinuity lies exactly half way between 2 grids.
>> They claimed that this will greatly improve the convergence.
>>
>>
>>
>> I have completed such experimental implementation in QuantLib. Besides
>> I do a comparison between "Grids Shift + Damping" and "Damping"
>> methods. The result is promising. The convergence speed is greatly
>> improved and is consistent with what Anderson and Piterbarg claimed.
>> The result can be referred from the attached Shift_experiment.xlsx file.
>>
>>
>>
>> To replicate my result, you can replacing the original files in
>> ql\methods\finitedifferences\meshers with the files I attached
>> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the
>> test program testPDEScheme.cpp
>>
>>
>>
>> The results is based on "Grids shift + 2 damping steps". Also you can
>> run the test program without replacing the mesher file to see what is
>> result of
>> "2 damping steps". Besides I also run through the QuantLIb test suite.
>> This change won't break any existing test case.
>>
>>
>>
>> Is anyone have some interest to have a look at this? I'd like to
>> create a pull request for this change if no one is against it.
>>
>>
>>
>> Regards,
>>
>> Cheng
>
>
> ----------------------------------------------------------------------------
> --
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method

[cheng l. <scr...@gm...>]

Hi Spanderen,

The numerical result says there is no much difference between these 2
methods for vanilla option:

The parameters are same as my previous example

Grids	Shift Grids + Damping	Damping
10	4.049015807	4.023573966
20	3.888731876	3.883259801
30	3.859347301	3.860949207
40	3.853164351	3.853494439
50	3.850117743	3.850127399
60	3.848403455	3.848320323
70	3.847346072	3.847233176
80	3.846453732	3.846532679
90	3.846028584	3.84605574
100	3.845716741	3.845717576
110	3.845481428	3.845467956
120	3.845299598	3.845277305
130	3.845111453	3.845129343
140	3.845005422	3.845012225
150	3.844918509	3.84491863
160	3.844846402	3.844841907
170	3.844785935	3.844778105
180	3.844717978	3.844724605
190	3.844676773	3.844679439
200	3.844641179	3.844641171
210	3.844307792	3.844307792

Regards,
Cheng

-----邮件原件-----
发件人: Cheng Li [mailto:scr...@gm...] 
发送时间: 2014年11月14日 20:09
收件人: 'Klaus Spanderen'; qua...@li...
主题: 答复: [Quantlib-dev] Grids shift trick to improve the convergence
speed PDE method

Hi Spanderen,

Let me do one for us. I'll come back to you when it is finished. IMO I think
the convergence speed won't improve as much as the case for digital since
there is no discontinuity in plain vanilla payoff.  

BTW, I agree with you that this will change the default behavior if using my
implementation. That is the reason I sent this all the developers to see
other's opinion before raise a pull request in github.

Regards,
Cheng

-----邮件原件-----
发件人: Klaus Spanderen [mailto:kl...@sp...]
发送时间: 2014年11月14日 14:42
收件人: qua...@li...
主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence speed
PDE method

Hi

cool!

The results are looking promising. Do you get a similar improvement if you
apply the shift trick to plain vanilla option.

The only thing we might consider is that we change behavior if the shift
becomes the default. 

regards
Klaus

On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
> Hi Team,
> 
> 
> 
> Current I am in an effort to improve the convergence speed of 
> FdBlackScholesVanillaEngine to digital option. The background is as
follows:
> 
> 
> 
> For digital option there is some discontinuity in the initial condition.
> Such discontinuity will cause the straight Crank-Nicolson method to 
> show severe odd-even effect. In current implementation, the pricing 
> engine will use several damping steps to suppress some effect. However 
> as claimed in Interest Rate Modeling. Section 2.5 p60 in V1 by 
> Anderson and Piterbarg, Damping steps is not adequate for such task.
> Referencing to Tavella and Randall's book, they suggest to shift the 
> grids to let the discontinuity lies exactly half way between 2 grids.
> They claimed that this will greatly improve the convergence.
> 
> 
> 
> I have completed such experimental implementation in QuantLib. Besides 
> I do a comparison between "Grids Shift + Damping" and "Damping"
> methods. The result is promising. The convergence speed is greatly 
> improved and is consistent with what Anderson and Piterbarg claimed.
> The result can be referred from the attached Shift_experiment.xlsx file.
> 
> 
> 
> To replicate my result, you can replacing the original files in 
> ql\methods\finitedifferences\meshers with the files I attached 
> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the 
> test program testPDEScheme.cpp
> 
> 
> 
> The results is based on "Grids shift + 2 damping steps". Also you can 
> run the test program without replacing the mesher file to see what is 
> result of
> "2 damping steps". Besides I also run through the QuantLIb test suite. 
> This change won't break any existing test case.
> 
> 
> 
> Is anyone have some interest to have a look at this? I'd like to 
> create a pull request for this change if no one is against it.
> 
> 
> 
> Regards,
> 
> Cheng


----------------------------------------------------------------------------
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method

[Cheng L. <scr...@gm...>]

Hi Spanderen,

Let me do one for us. I'll come back to you when it is finished. IMO I think
the convergence speed won't improve as much as the case for digital since
there is no discontinuity in plain vanilla payoff.  

BTW, I agree with you that this will change the default behavior if using my
implementation. That is the reason I sent this all the developers to see
other's opinion before raise a pull request in github.

Regards,
Cheng

-----邮件原件-----
发件人: Klaus Spanderen [mailto:kl...@sp...] 
发送时间: 2014年11月14日 14:42
收件人: qua...@li...
主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence speed
PDE method

Hi

cool!

The results are looking promising. Do you get a similar improvement if you
apply the shift trick to plain vanilla option.

The only thing we might consider is that we change behavior if the shift
becomes the default. 

regards
Klaus

On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
> Hi Team,
> 
> 
> 
> Current I am in an effort to improve the convergence speed of 
> FdBlackScholesVanillaEngine to digital option. The background is as
follows:
> 
> 
> 
> For digital option there is some discontinuity in the initial condition.
> Such discontinuity will cause the straight Crank-Nicolson method to 
> show severe odd-even effect. In current implementation, the pricing 
> engine will use several damping steps to suppress some effect. However 
> as claimed in Interest Rate Modeling. Section 2.5 p60 in V1 by 
> Anderson and Piterbarg, Damping steps is not adequate for such task. 
> Referencing to Tavella and Randall's book, they suggest to shift the 
> grids to let the discontinuity lies exactly half way between 2 grids. 
> They claimed that this will greatly improve the convergence.
> 
> 
> 
> I have completed such experimental implementation in QuantLib. Besides 
> I do a comparison between "Grids Shift + Damping" and "Damping" 
> methods. The result is promising. The convergence speed is greatly 
> improved and is consistent with what Anderson and Piterbarg claimed. 
> The result can be referred from the attached Shift_experiment.xlsx file.
> 
> 
> 
> To replicate my result, you can replacing the original files in 
> ql\methods\finitedifferences\meshers with the files I attached 
> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the 
> test program testPDEScheme.cpp
> 
> 
> 
> The results is based on "Grids shift + 2 damping steps". Also you can 
> run the test program without replacing the mesher file to see what is 
> result of
> "2 damping steps". Besides I also run through the QuantLIb test suite. 
> This change won't break any existing test case.
> 
> 
> 
> Is anyone have some interest to have a look at this? I'd like to 
> create a pull request for this change if no one is against it.
> 
> 
> 
> Regards,
> 
> Cheng


----------------------------------------------------------------------------
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Grids shift trick to improve the convergence speed PDE method

[Klaus S. <kl...@sp...>]

Hi

cool!

The results are looking promising. Do you get a similar improvement if you 
apply the shift trick to plain vanilla option.

The only thing we might consider is that we change behavior if the shift 
becomes the default. 

regards
Klaus

On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote:
> Hi Team,
> 
> 
> 
> Current I am in an effort to improve the convergence speed of
> FdBlackScholesVanillaEngine to digital option. The background is as follows:
> 
> 
> 
> For digital option there is some discontinuity in the initial condition.
> Such discontinuity will cause the straight Crank-Nicolson method to show
> severe odd-even effect. In current implementation, the pricing engine will
> use several damping steps to suppress some effect. However as claimed in
> Interest Rate Modeling. Section 2.5 p60 in V1 by Anderson and Piterbarg,
> Damping steps is not adequate for such task. Referencing to Tavella and
> Randall's book, they suggest to shift the grids to let the discontinuity
> lies exactly half way between 2 grids. They claimed that this will greatly
> improve the convergence.
> 
> 
> 
> I have completed such experimental implementation in QuantLib. Besides I do
> a comparison between "Grids Shift + Damping" and "Damping" methods. The
> result is promising. The convergence speed is greatly improved and is
> consistent with what Anderson and Piterbarg claimed. The result can be
> referred from the attached Shift_experiment.xlsx file.
> 
> 
> 
> To replicate my result, you can replacing the original files in
> ql\methods\finitedifferences\meshers with the files I attached
> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the test
> program testPDEScheme.cpp
> 
> 
> 
> The results is based on "Grids shift + 2 damping steps". Also you can run
> the test program without replacing the mesher file to see what is result of
> "2 damping steps". Besides I also run through the QuantLIb test suite. This
> change won't break any existing test case.
> 
> 
> 
> Is anyone have some interest to have a look at this? I'd like to create a
> pull request for this change if no one is against it.
> 
> 
> 
> Regards,
> 
> Cheng