quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] QuantLib 1.29 released

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

Hello Roberto,
    no, it's still a bad idea to share objects between threads.  Like in
previous releases, the Settings class and other singletons can be
per-thread instead of globals depending on a configuration switch, but the
code in itself is not multi-threaded.  What changed is only that, in order
to enable per-thread singletons, you no longer need to explicitly define
the sessionId function.  It's a convenience.

Hope this helps,
    Luigi


On Tue, Jan 17, 2023 at 12:14 PM Roberto Cocchi <
rob...@so...> wrote:

> Hi sorry a question:
>
>    - *End of support:* as announced in the notes for the previous
>    release, this release no longer manages thread-local singletons via a
>    user-provided sessionId function, and therefore the latter is no
>    longer needed. Instead, the code now uses the built-in language support for
>    thread-local variables. Thanks go to Peter Caspers.
>
> Does this mean QL is fully MultiThreaded?
>
> Thanks
> Roberto
> ------------------------------
> *From: *"luigi ballabio" <lui...@gm...>
> *To: *"QuantLib-users" <qua...@li...>, "QuantLib
> developers" <qua...@li...>, "QuantLib announce" <
> qua...@li...>
> *Sent: *Tuesday, 17 January, 2023 11:23:37
> *Subject: *[Quantlib-users] QuantLib 1.29 released
>
> QuantLib 1.29 has been released and is available for download at <
> https://www.quantlib.org/download.shtml
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.quantlib.org%2Fdownload.shtml&e=4ea62f8f&h=232ff9de&f=y&p=n>
> >.
>
> The list of changes for this release is at <
> https://www.quantlib.org/reference/history.html
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.quantlib.org%2Freference%2Fhistory.html&e=4ea62f8f&h=808f169d&f=y&p=n>
> >.
>
> If you have any problems with this release, please report them here on the
> QuantLib mailing list (<qua...@li...>), or open a
> GitHub issue at <https://github.com/lballabio/quantlib/issues
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Flballabio%2Fquantlib%2Fissues&e=4ea62f8f&h=281f3799&f=y&p=n>
> >.
>
>
> --
> EXTERNAL E-MAIL. Message from outside of SoftSolutions! Do not click
> links or download/open attachments unless you trust the sender and believe
> the content is safe.
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
>
> https://urlsand.esvalabs.com/?u=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&e=4ea62f8f&h=2a391e00&f=y&p=n
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QuantLib 1.29 released

[Roberto C. <rob...@so...>]

Hi sorry a question: 


    * End of support: as announced in the notes for the previous release, this release no longer manages thread-local singletons via a user-provided sessionId function, and therefore the latter is no longer needed. Instead, the code now uses the built-in language support for thread-local variables. Thanks go to Peter Caspers. 
Does this mean QL is fully MultiThreaded? 

Thanks 
Roberto 

From: "luigi ballabio" <lui...@gm...> 
To: "QuantLib-users" <qua...@li...>, "QuantLib developers" <qua...@li...>, "QuantLib announce" <qua...@li...> 
Sent: Tuesday, 17 January, 2023 11:23:37 
Subject: [Quantlib-users] QuantLib 1.29 released 

QuantLib 1.29 has been released and is available for download at < [ https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.quantlib.org%2Fdownload.shtml&e=4ea62f8f&h=232ff9de&f=y&p=n | https://www.quantlib.org/download.shtml ] >. 

The list of changes for this release is at < [ https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.quantlib.org%2Freference%2Fhistory.html&e=4ea62f8f&h=808f169d&f=y&p=n | https://www.quantlib.org/reference/history.html ] >. 

If you have any problems with this release, please report them here on the QuantLib mailing list (< [ mailto:qua...@li... | qua...@li... ] >), or open a GitHub issue at < [ https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Flballabio%2Fquantlib%2Fissues&e=4ea62f8f&h=281f3799&f=y&p=n | https://github.com/lballabio/quantlib/issues ] >. 



-- 
EXTERNAL E-MAIL. Message from outside of SoftSolutions! Do not click links or download/open attachments unless you trust the sender and believe the content is safe. 


_______________________________________________ 
QuantLib-users mailing list 
Qua...@li... 
https://urlsand.esvalabs.com/?u=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&e=4ea62f8f&h=2a391e00&f=y&p=n 

[Quantlib-users] QuantLib 1.29 released

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

QuantLib 1.29 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

The list of changes for this release is at <
https://www.quantlib.org/reference/history.html>.

If you have any problems with this release, please report them here on the
QuantLib mailing list (<qua...@li...>), or open a
GitHub issue at <https://github.com/lballabio/quantlib/issues>.

Re: [Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Hi Peter,

Apologies for the delayed response.

I have little expertise on the current practices around cap pricing, but 
I asked around and I can confirm what you wrote, albeit only for front 
desk trading.

Risk management applications often need to take into account ATM vols, 
mainly because the regulators demand it.

It is also true that ATM vols are generally published - for example in 
regular Bloomberg screens -, which implies that there must be some use 
for it.

The good news is that I have managed to bootstrap the ATM vols 
successfully in ORE by means of the sparse table using the class 
CapFloorTermVolSurfaceSparse

Ioannis

On 1/11/2023 12:44 PM, Peter Caspers wrote:
> Hi Ioannis
>
> no it is not possible at the moment to include ATM quotes, unfortunately.
>
> By the way what is your general view on this, i.e. is it useful to
> include ATM quotes? Sometimes I hear these are not traded much and
> therefore you might be better off building the surface from fixed
> strike quotes.
>
> Thanks
> Peter
>
> On Tue, 10 Jan 2023 at 21:18, Ioannis Rigopoulos <qua...@de...> wrote:
>> Peter,
>>
>> I don't know if what I describe below relates to what you wrote about
>> IborCoupon  versus OvernightIndexedCoupon.
>>
>> While my bootstraping of a strike/tenor vol matrix runs smoothly, I
>> encounter a serious problem when I tried to bootstrap the combination
>> consisting of an atm tenor-only vol vector and a strike/tenor vol matrix.
>>
>> The current code for the method
>> OptionletStripperWithAtm<TimeInterpolator,
>> SmileInterpolator>::performCalculations() contains the following:
>>
>> if (isOis) {
>>
>>       QL_FAIL("OIS cap vol stripping with ATM not yet supported.");
>>
>> }
>>
>> I tried to add my own code in that place, but I realized that the whole
>> logic in OptionletStripperWithAtm is based on instruments of type
>> QuantLib::CapFloor which cannot process correctly oi term rates.
>>
>> Is there any way to solve this problem in the current ORE version?
>>
>> In the mean time I will be trying to use the type
>> CapFloorTermVolSurfaceSparse after having calculated manually the atm
>> strikes of the caps in the atm vol vector. Hopefully this would work!
>>
>> Ioannis
>>
>> On 1/10/2023 1:12 PM, Ioannis Rigopoulos wrote:
>>> Let me also share one more thought regarding IborIndex and IborCoupon.
>>>
>>> I understand these two types are used almost everywhere in QuantLib
>>> for good historical reasons and is therefore reasonable to elevate the
>>> concept represented by IborIndex to include special types of term
>>> rates, such as average overnight rates.
>>>
>>> I would then find it practical to enhance a bit the definition of
>>> TermRateIndex with a boolean flag so that it captures both types of
>>> averages, the forward looking average and the backward looking average.
>>>
>>> This would make the overall code smaller and simpler since the
>>> IborCoupon would then represent both types of average and would also
>>> make the OvernightIndexedCoupon redundant.
>>>
>>> Ioannis
>>>
>>> On 1/9/2023 9:23 PM, Ioannis Rigopoulos wrote:
>>>> Hi Peter,
>>>>
>>>> Thanks for letting me know that forward looking oi coupons are
>>>> modeled through IborCoupon. It does make sense since the IborCoupon
>>>> referencing a non-RFR ibor rate has always been forward looking.
>>>>
>>>> I will make the link to QuantLib::CapFloor and test how it will work.
>>>>
>>>> Ioannis
>>>>
>>>> On 1/9/2023 7:20 PM, Peter Caspers wrote:
>>>>> Hi Jacek,
>>>>>
>>>>> I don't think it is at the moment. Even GSR won't work properly for
>>>>> OvernightIndexedCoupon.
>>>>>
>>>>> Thank you
>>>>> Peter
>>>>>
>>>>> On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>>>>>> Hi Peter,
>>>>>> Is this formula implemented in Quantlib as well? I'm trying to
>>>>>> price RFR caps, but couldn't find suitable classes. Is gsr the only
>>>>>> option?
>>>>>>
>>>>>> Jacek
>>>>>>
>>>>>> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers
>>>>>> <pca...@gm...> napisał:
>>>>>>> Thanks Ioannis!
>>>>>>>
>>>>>>> OvernightIndexedCoupon is always backward looking. We model forward
>>>>>>> looking term rates using the TermRateIndex class (derived from
>>>>>>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>>>>>>> other IborIndex - based classes.
>>>>>>>
>>>>>>> Does that make sense?
>>>>>>>
>>>>>>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos
>>>>>>> <qua...@de...> wrote:
>>>>>>>> Hi Peter,
>>>>>>>>
>>>>>>>> Yes. This now makes sense. I was not aware of this formula. Thank
>>>>>>>> you
>>>>>>>> for sharing the paper as it helped me understand the details of
>>>>>>>> overnight index cap/floor pricing.
>>>>>>>>
>>>>>>>> Thanks to ORE, I completed a sofr cap pricing for a client and
>>>>>>>> everything went very smoothly. So, kudos for the excellent work!
>>>>>>>> I do
>>>>>>>> mention of course that the analytics come from ORE/Acadia.
>>>>>>>>
>>>>>>>> Just parenthetically, I noticed that the
>>>>>>>> QuantExt::OvernightIndexedCoupon does not distinguish between
>>>>>>>> forward
>>>>>>>> and backward looking term rates, which is fine for linear
>>>>>>>> contracts, but
>>>>>>>> not so for caps or swaptions because a backward looking rate
>>>>>>>> exhibits
>>>>>>>> higher variance than its forward looking counterpart. Your formulas
>>>>>>>> imply that you treat the OvernightIndexedCoupon as if it were
>>>>>>>> backward
>>>>>>>> looking. I would be curious to know if you plan to add a
>>>>>>>> corresponding
>>>>>>>> boolean flag in the OvernightIndexedCoupon constructor and adjust
>>>>>>>> the
>>>>>>>> vol code discussed here to account for both forward and backward
>>>>>>>> looking
>>>>>>>> cases.
>>>>>>>>
>>>>>>>> Ioannis
>>>>>>>>
>>>>>>>> On 1/5/2023 10:38 AM, Peter Caspers wrote:
>>>>>>>>> Hi Ioannis
>>>>>>>>>
>>>>>>>>> this is a typo, the line should actually be
>>>>>>>>>
>>>>>>>>>                T += std::pow(fixingEndTime - T, 3.0) /
>>>>>>>>> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>>>>>>>>>
>>>>>>>>> This corresponds to the formula for v_j^B at the end of section
>>>>>>>>> 6.3 in
>>>>>>>>> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>>>>>>>>>
>>>>>>>>> We will fix this shortly.
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos
>>>>>>>>> <qua...@de...> wrote:
>>>>>>>>>> Does anyone have a clue on why the statement (found in
>>>>>>>>>> blackovernightindexedcouponpricer.cpp)
>>>>>>>>>>
>>>>>>>>>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime
>>>>>>>>>> - T, 2.0)
>>>>>>>>>> / 3.0;
>>>>>>>>>>
>>>>>>>>>> is not coded much more simply as
>>>>>>>>>>
>>>>>>>>>> T +=( fixingEndTime - T ) / 3.0;
>>>>>>>>>>
>>>>>>>>>> The two variables T and fixingEndTime  are both double.
>>>>>>>>>>
>>>>>>>>>> I am only asking in case there is some sort of sophisticated
>>>>>>>>>> trick that
>>>>>>>>>> I am missing.
>>>>>>>>>>
>>>>>>>>>> Ioannis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>>>>>> www.avast.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> QuantLib-users mailing list
>>>>>>>>>> Qua...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>> --
>>>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>>>> www.avast.com
>>>>>>> _______________________________________________
>>>>>>> QuantLib-users mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] CPI laggedFixing

[Anastasia A. <ana...@di...>]

Thank you, Luigi!
________________________________
From: Luigi Ballabio <lui...@gm...>
Sent: Wednesday, January 11, 2023 3:03 PM
To: Anastasia Afanaseva <ana...@di...>
Cc: qua...@li... <qua...@li...>
Subject: Re: [Quantlib-users] CPI laggedFixing

Hello Anastasia,
    the index fixing used by the cashflow probably takes into account the observation lag.  CPI::laggedFixing will work, but it's still not exported to Python in version 1.28.  It will be available in version 1.29, hopefully out in a week or two.  In the meantime, you can do in Python what that function does in C++ (the code is at <https://github.com/lballabio/QuantLib/blob/QuantLib-v1.28/ql/indexes/inflationindex.cpp#L28>); you'll also have to translate inflationPeriod (<https://github.com/lballabio/QuantLib/blob/QuantLib-v1.28/ql/termstructures/inflationtermstructure.cpp#L349>).

Hope this helps,
    Luigi





On Tue, Jan 10, 2023 at 3:42 AM Anastasia Afanaseva <ana...@di...<mailto:ana...@di...>> wrote:
Hi!

I have a problem with the CPI bond.
I want to extract the index fixing on a daily basis (that fixing which is calculated within the cash flow including the inflation lag).

If I apply the index.fixing(ql.Date(...) function, I get the value from the interpolated curve, but not the index which is taken into account when calculating the CPI coupon.

Does the new method from version 1.26 laggedFixing solve this problem ? I did not get how it works, unfortunately.

I have tried different options, ql.CPIBond.laggedFixing((index, ql.Date(31,12,2022), ql.Period(3, ql.Months), ql.CPI.Linear), but the errors like type object 'CPIBond' has no attribute 'laggedFixing' and others occur .

Could anyone advise how to use this method correctly?

Warm regards,
Anastasia



_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] CPI laggedFixing

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

Hello Anastasia,
    the index fixing used by the cashflow probably takes into account the
observation lag.  CPI::laggedFixing will work, but it's still not exported
to Python in version 1.28.  It will be available in version 1.29, hopefully
out in a week or two.  In the meantime, you can do in Python what that
function does in C++ (the code is at <
https://github.com/lballabio/QuantLib/blob/QuantLib-v1.28/ql/indexes/inflationindex.cpp#L28>);
you'll also have to translate inflationPeriod (<
https://github.com/lballabio/QuantLib/blob/QuantLib-v1.28/ql/termstructures/inflationtermstructure.cpp#L349
>).

Hope this helps,
    Luigi





On Tue, Jan 10, 2023 at 3:42 AM Anastasia Afanaseva <
ana...@di...> wrote:

> Hi!
>
> I have a problem with the CPI bond.
> I want to extract the index fixing on a daily basis (that fixing which is
> calculated within the cash flow including the inflation lag).
>
> If I apply the index.fixing(ql.Date(...) function, I get the value from
> the interpolated curve, but not the index which is taken into account when
> calculating the CPI coupon.
>
> Does the new method from version 1.26 laggedFixing solve this problem ? I
> did not get how it works, unfortunately.
>
> I have tried different options, ql.CPIBond.laggedFixing((index,
> ql.Date(31,12,2022), ql.Period(3, ql.Months), ql.CPI.Linear), but the
> errors like type object 'CPIBond' has no attribute 'laggedFixing' and
> others occur .
>
> Could anyone advise how to use this method correctly?
>
> Warm regards,
> Anastasia
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Qurious finding in ORE code

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

Hi Ioannis

no it is not possible at the moment to include ATM quotes, unfortunately.

By the way what is your general view on this, i.e. is it useful to
include ATM quotes? Sometimes I hear these are not traded much and
therefore you might be better off building the surface from fixed
strike quotes.

Thanks
Peter

On Tue, 10 Jan 2023 at 21:18, Ioannis Rigopoulos <qua...@de...> wrote:
>
> Peter,
>
> I don't know if what I describe below relates to what you wrote about
> IborCoupon  versus OvernightIndexedCoupon.
>
> While my bootstraping of a strike/tenor vol matrix runs smoothly, I
> encounter a serious problem when I tried to bootstrap the combination
> consisting of an atm tenor-only vol vector and a strike/tenor vol matrix.
>
> The current code for the method
> OptionletStripperWithAtm<TimeInterpolator,
> SmileInterpolator>::performCalculations() contains the following:
>
> if (isOis) {
>
>      QL_FAIL("OIS cap vol stripping with ATM not yet supported.");
>
> }
>
> I tried to add my own code in that place, but I realized that the whole
> logic in OptionletStripperWithAtm is based on instruments of type
> QuantLib::CapFloor which cannot process correctly oi term rates.
>
> Is there any way to solve this problem in the current ORE version?
>
> In the mean time I will be trying to use the type
> CapFloorTermVolSurfaceSparse after having calculated manually the atm
> strikes of the caps in the atm vol vector. Hopefully this would work!
>
> Ioannis
>
> On 1/10/2023 1:12 PM, Ioannis Rigopoulos wrote:
> > Let me also share one more thought regarding IborIndex and IborCoupon.
> >
> > I understand these two types are used almost everywhere in QuantLib
> > for good historical reasons and is therefore reasonable to elevate the
> > concept represented by IborIndex to include special types of term
> > rates, such as average overnight rates.
> >
> > I would then find it practical to enhance a bit the definition of
> > TermRateIndex with a boolean flag so that it captures both types of
> > averages, the forward looking average and the backward looking average.
> >
> > This would make the overall code smaller and simpler since the
> > IborCoupon would then represent both types of average and would also
> > make the OvernightIndexedCoupon redundant.
> >
> > Ioannis
> >
> > On 1/9/2023 9:23 PM, Ioannis Rigopoulos wrote:
> >> Hi Peter,
> >>
> >> Thanks for letting me know that forward looking oi coupons are
> >> modeled through IborCoupon. It does make sense since the IborCoupon
> >> referencing a non-RFR ibor rate has always been forward looking.
> >>
> >> I will make the link to QuantLib::CapFloor and test how it will work.
> >>
> >> Ioannis
> >>
> >> On 1/9/2023 7:20 PM, Peter Caspers wrote:
> >>> Hi Jacek,
> >>>
> >>> I don't think it is at the moment. Even GSR won't work properly for
> >>> OvernightIndexedCoupon.
> >>>
> >>> Thank you
> >>> Peter
> >>>
> >>> On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
> >>>> Hi Peter,
> >>>> Is this formula implemented in Quantlib as well? I'm trying to
> >>>> price RFR caps, but couldn't find suitable classes. Is gsr the only
> >>>> option?
> >>>>
> >>>> Jacek
> >>>>
> >>>> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers
> >>>> <pca...@gm...> napisał:
> >>>>> Thanks Ioannis!
> >>>>>
> >>>>> OvernightIndexedCoupon is always backward looking. We model forward
> >>>>> looking term rates using the TermRateIndex class (derived from
> >>>>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
> >>>>> other IborIndex - based classes.
> >>>>>
> >>>>> Does that make sense?
> >>>>>
> >>>>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos
> >>>>> <qua...@de...> wrote:
> >>>>>> Hi Peter,
> >>>>>>
> >>>>>> Yes. This now makes sense. I was not aware of this formula. Thank
> >>>>>> you
> >>>>>> for sharing the paper as it helped me understand the details of
> >>>>>> overnight index cap/floor pricing.
> >>>>>>
> >>>>>> Thanks to ORE, I completed a sofr cap pricing for a client and
> >>>>>> everything went very smoothly. So, kudos for the excellent work!
> >>>>>> I do
> >>>>>> mention of course that the analytics come from ORE/Acadia.
> >>>>>>
> >>>>>> Just parenthetically, I noticed that the
> >>>>>> QuantExt::OvernightIndexedCoupon does not distinguish between
> >>>>>> forward
> >>>>>> and backward looking term rates, which is fine for linear
> >>>>>> contracts, but
> >>>>>> not so for caps or swaptions because a backward looking rate
> >>>>>> exhibits
> >>>>>> higher variance than its forward looking counterpart. Your formulas
> >>>>>> imply that you treat the OvernightIndexedCoupon as if it were
> >>>>>> backward
> >>>>>> looking. I would be curious to know if you plan to add a
> >>>>>> corresponding
> >>>>>> boolean flag in the OvernightIndexedCoupon constructor and adjust
> >>>>>> the
> >>>>>> vol code discussed here to account for both forward and backward
> >>>>>> looking
> >>>>>> cases.
> >>>>>>
> >>>>>> Ioannis
> >>>>>>
> >>>>>> On 1/5/2023 10:38 AM, Peter Caspers wrote:
> >>>>>>> Hi Ioannis
> >>>>>>>
> >>>>>>> this is a typo, the line should actually be
> >>>>>>>
> >>>>>>>               T += std::pow(fixingEndTime - T, 3.0) /
> >>>>>>> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
> >>>>>>>
> >>>>>>> This corresponds to the formula for v_j^B at the end of section
> >>>>>>> 6.3 in
> >>>>>>> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
> >>>>>>>
> >>>>>>> We will fix this shortly.
> >>>>>>>
> >>>>>>> Thank you
> >>>>>>> Peter
> >>>>>>>
> >>>>>>> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos
> >>>>>>> <qua...@de...> wrote:
> >>>>>>>> Does anyone have a clue on why the statement (found in
> >>>>>>>> blackovernightindexedcouponpricer.cpp)
> >>>>>>>>
> >>>>>>>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime
> >>>>>>>> - T, 2.0)
> >>>>>>>> / 3.0;
> >>>>>>>>
> >>>>>>>> is not coded much more simply as
> >>>>>>>>
> >>>>>>>> T +=( fixingEndTime - T ) / 3.0;
> >>>>>>>>
> >>>>>>>> The two variables T and fixingEndTime  are both double.
> >>>>>>>>
> >>>>>>>> I am only asking in case there is some sort of sophisticated
> >>>>>>>> trick that
> >>>>>>>> I am missing.
> >>>>>>>>
> >>>>>>>> Ioannis
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> >>>>>>>> www.avast.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> QuantLib-users mailing list
> >>>>>>>> Qua...@li...
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>>>>> --
> >>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> >>>>>> www.avast.com
> >>>>>
> >>>>> _______________________________________________
> >>>>> QuantLib-users mailing list
> >>>>> Qua...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>>>>
> >>
> >
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Peter,

I don't know if what I describe below relates to what you wrote about 
IborCoupon  versus OvernightIndexedCoupon.

While my bootstraping of a strike/tenor vol matrix runs smoothly, I 
encounter a serious problem when I tried to bootstrap the combination 
consisting of an atm tenor-only vol vector and a strike/tenor vol matrix.

The current code for the method 
OptionletStripperWithAtm<TimeInterpolator, 
SmileInterpolator>::performCalculations() contains the following:

if (isOis) {

     QL_FAIL("OIS cap vol stripping with ATM not yet supported.");

}

I tried to add my own code in that place, but I realized that the whole 
logic in OptionletStripperWithAtm is based on instruments of type 
QuantLib::CapFloor which cannot process correctly oi term rates.

Is there any way to solve this problem in the current ORE version?

In the mean time I will be trying to use the type 
CapFloorTermVolSurfaceSparse after having calculated manually the atm 
strikes of the caps in the atm vol vector. Hopefully this would work!

Ioannis

On 1/10/2023 1:12 PM, Ioannis Rigopoulos wrote:
> Let me also share one more thought regarding IborIndex and IborCoupon.
>
> I understand these two types are used almost everywhere in QuantLib 
> for good historical reasons and is therefore reasonable to elevate the 
> concept represented by IborIndex to include special types of term 
> rates, such as average overnight rates.
>
> I would then find it practical to enhance a bit the definition of 
> TermRateIndex with a boolean flag so that it captures both types of 
> averages, the forward looking average and the backward looking average.
>
> This would make the overall code smaller and simpler since the 
> IborCoupon would then represent both types of average and would also 
> make the OvernightIndexedCoupon redundant.
>
> Ioannis
>
> On 1/9/2023 9:23 PM, Ioannis Rigopoulos wrote:
>> Hi Peter,
>>
>> Thanks for letting me know that forward looking oi coupons are 
>> modeled through IborCoupon. It does make sense since the IborCoupon 
>> referencing a non-RFR ibor rate has always been forward looking.
>>
>> I will make the link to QuantLib::CapFloor and test how it will work.
>>
>> Ioannis
>>
>> On 1/9/2023 7:20 PM, Peter Caspers wrote:
>>> Hi Jacek,
>>>
>>> I don't think it is at the moment. Even GSR won't work properly for
>>> OvernightIndexedCoupon.
>>>
>>> Thank you
>>> Peter
>>>
>>> On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>>>> Hi Peter,
>>>> Is this formula implemented in Quantlib as well? I'm trying to 
>>>> price RFR caps, but couldn't find suitable classes. Is gsr the only 
>>>> option?
>>>>
>>>> Jacek
>>>>
>>>> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers 
>>>> <pca...@gm...> napisał:
>>>>> Thanks Ioannis!
>>>>>
>>>>> OvernightIndexedCoupon is always backward looking. We model forward
>>>>> looking term rates using the TermRateIndex class (derived from
>>>>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>>>>> other IborIndex - based classes.
>>>>>
>>>>> Does that make sense?
>>>>>
>>>>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos 
>>>>> <qua...@de...> wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> Yes. This now makes sense. I was not aware of this formula. Thank 
>>>>>> you
>>>>>> for sharing the paper as it helped me understand the details of
>>>>>> overnight index cap/floor pricing.
>>>>>>
>>>>>> Thanks to ORE, I completed a sofr cap pricing for a client and
>>>>>> everything went very smoothly. So, kudos for the excellent work! 
>>>>>> I do
>>>>>> mention of course that the analytics come from ORE/Acadia.
>>>>>>
>>>>>> Just parenthetically, I noticed that the
>>>>>> QuantExt::OvernightIndexedCoupon does not distinguish between 
>>>>>> forward
>>>>>> and backward looking term rates, which is fine for linear 
>>>>>> contracts, but
>>>>>> not so for caps or swaptions because a backward looking rate 
>>>>>> exhibits
>>>>>> higher variance than its forward looking counterpart. Your formulas
>>>>>> imply that you treat the OvernightIndexedCoupon as if it were 
>>>>>> backward
>>>>>> looking. I would be curious to know if you plan to add a 
>>>>>> corresponding
>>>>>> boolean flag in the OvernightIndexedCoupon constructor and adjust 
>>>>>> the
>>>>>> vol code discussed here to account for both forward and backward 
>>>>>> looking
>>>>>> cases.
>>>>>>
>>>>>> Ioannis
>>>>>>
>>>>>> On 1/5/2023 10:38 AM, Peter Caspers wrote:
>>>>>>> Hi Ioannis
>>>>>>>
>>>>>>> this is a typo, the line should actually be
>>>>>>>
>>>>>>>               T += std::pow(fixingEndTime - T, 3.0) /
>>>>>>> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>>>>>>>
>>>>>>> This corresponds to the formula for v_j^B at the end of section 
>>>>>>> 6.3 in
>>>>>>> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>>>>>>>
>>>>>>> We will fix this shortly.
>>>>>>>
>>>>>>> Thank you
>>>>>>> Peter
>>>>>>>
>>>>>>> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos 
>>>>>>> <qua...@de...> wrote:
>>>>>>>> Does anyone have a clue on why the statement (found in
>>>>>>>> blackovernightindexedcouponpricer.cpp)
>>>>>>>>
>>>>>>>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime 
>>>>>>>> - T, 2.0)
>>>>>>>> / 3.0;
>>>>>>>>
>>>>>>>> is not coded much more simply as
>>>>>>>>
>>>>>>>> T +=( fixingEndTime - T ) / 3.0;
>>>>>>>>
>>>>>>>> The two variables T and fixingEndTime  are both double.
>>>>>>>>
>>>>>>>> I am only asking in case there is some sort of sophisticated 
>>>>>>>> trick that
>>>>>>>> I am missing.
>>>>>>>>
>>>>>>>> Ioannis
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>>>> www.avast.com
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> QuantLib-users mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>> -- 
>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>> www.avast.com
>>>>>
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Let me also share one more thought regarding IborIndex and IborCoupon.

I understand these two types are used almost everywhere in QuantLib for 
good historical reasons and is therefore reasonable to elevate the 
concept represented by IborIndex to include special types of term rates, 
such as average overnight rates.

I would then find it practical to enhance a bit the definition of 
TermRateIndex with a boolean flag so that it captures both types of 
averages, the forward looking average and the backward looking average.

This would make the overall code smaller and simpler since the 
IborCoupon would then represent both types of average and would also 
make the OvernightIndexedCoupon redundant.

Ioannis

On 1/9/2023 9:23 PM, Ioannis Rigopoulos wrote:
> Hi Peter,
>
> Thanks for letting me know that forward looking oi coupons are modeled 
> through IborCoupon. It does make sense since the IborCoupon 
> referencing a non-RFR ibor rate has always been forward looking.
>
> I will make the link to QuantLib::CapFloor and test how it will work.
>
> Ioannis
>
> On 1/9/2023 7:20 PM, Peter Caspers wrote:
>> Hi Jacek,
>>
>> I don't think it is at the moment. Even GSR won't work properly for
>> OvernightIndexedCoupon.
>>
>> Thank you
>> Peter
>>
>> On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>>> Hi Peter,
>>> Is this formula implemented in Quantlib as well? I'm trying to price 
>>> RFR caps, but couldn't find suitable classes. Is gsr the only option?
>>>
>>> Jacek
>>>
>>> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers 
>>> <pca...@gm...> napisał:
>>>> Thanks Ioannis!
>>>>
>>>> OvernightIndexedCoupon is always backward looking. We model forward
>>>> looking term rates using the TermRateIndex class (derived from
>>>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>>>> other IborIndex - based classes.
>>>>
>>>> Does that make sense?
>>>>
>>>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos 
>>>> <qua...@de...> wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Yes. This now makes sense. I was not aware of this formula. Thank you
>>>>> for sharing the paper as it helped me understand the details of
>>>>> overnight index cap/floor pricing.
>>>>>
>>>>> Thanks to ORE, I completed a sofr cap pricing for a client and
>>>>> everything went very smoothly. So, kudos for the excellent work! I do
>>>>> mention of course that the analytics come from ORE/Acadia.
>>>>>
>>>>> Just parenthetically, I noticed that the
>>>>> QuantExt::OvernightIndexedCoupon does not distinguish between forward
>>>>> and backward looking term rates, which is fine for linear 
>>>>> contracts, but
>>>>> not so for caps or swaptions because a backward looking rate exhibits
>>>>> higher variance than its forward looking counterpart. Your formulas
>>>>> imply that you treat the OvernightIndexedCoupon as if it were 
>>>>> backward
>>>>> looking. I would be curious to know if you plan to add a 
>>>>> corresponding
>>>>> boolean flag in the OvernightIndexedCoupon constructor and adjust the
>>>>> vol code discussed here to account for both forward and backward 
>>>>> looking
>>>>> cases.
>>>>>
>>>>> Ioannis
>>>>>
>>>>> On 1/5/2023 10:38 AM, Peter Caspers wrote:
>>>>>> Hi Ioannis
>>>>>>
>>>>>> this is a typo, the line should actually be
>>>>>>
>>>>>>               T += std::pow(fixingEndTime - T, 3.0) /
>>>>>> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>>>>>>
>>>>>> This corresponds to the formula for v_j^B at the end of section 
>>>>>> 6.3 in
>>>>>> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>>>>>>
>>>>>> We will fix this shortly.
>>>>>>
>>>>>> Thank you
>>>>>> Peter
>>>>>>
>>>>>> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos 
>>>>>> <qua...@de...> wrote:
>>>>>>> Does anyone have a clue on why the statement (found in
>>>>>>> blackovernightindexedcouponpricer.cpp)
>>>>>>>
>>>>>>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - 
>>>>>>> T, 2.0)
>>>>>>> / 3.0;
>>>>>>>
>>>>>>> is not coded much more simply as
>>>>>>>
>>>>>>> T +=( fixingEndTime - T ) / 3.0;
>>>>>>>
>>>>>>> The two variables T and fixingEndTime  are both double.
>>>>>>>
>>>>>>> I am only asking in case there is some sort of sophisticated 
>>>>>>> trick that
>>>>>>> I am missing.
>>>>>>>
>>>>>>> Ioannis
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>>> www.avast.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> QuantLib-users mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>> -- 
>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>> www.avast.com
>>>>
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>

[Quantlib-users] Release candidate for version 1.29

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

Hello everybody,
    I just published a RC for version 1.29 at <
https://github.com/lballabio/QuantLib/releases/tag/1.29rc>.  If you have
some time, please give it a spin and report any problems here on the
mailing list.  Thanks!

Luigi

[Quantlib-users] CPI laggedFixing

[Anastasia A. <ana...@di...>]

Hi!

I have a problem with the CPI bond.
I want to extract the index fixing on a daily basis (that fixing which is calculated within the cash flow including the inflation lag).

If I apply the index.fixing(ql.Date(...) function, I get the value from the interpolated curve, but not the index which is taken into account when calculating the CPI coupon.

Does the new method from version 1.26 laggedFixing solve this problem ? I did not get how it works, unfortunately.

I have tried different options, ql.CPIBond.laggedFixing((index, ql.Date(31,12,2022), ql.Period(3, ql.Months), ql.CPI.Linear), but the errors like type object 'CPIBond' has no attribute 'laggedFixing' and others occur .

Could anyone advise how to use this method correctly?

Warm regards,
Anastasia

Re: [Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Hi Peter,

Thanks for letting me know that forward looking oi coupons are modeled 
through IborCoupon. It does make sense since the IborCoupon referencing 
a non-RFR ibor rate has always been forward looking.

I will make the link to QuantLib::CapFloor and test how it will work.

Ioannis

On 1/9/2023 7:20 PM, Peter Caspers wrote:
> Hi Jacek,
>
> I don't think it is at the moment. Even GSR won't work properly for
> OvernightIndexedCoupon.
>
> Thank you
> Peter
>
> On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>> Hi Peter,
>> Is this formula implemented in Quantlib as well? I'm trying to price RFR caps, but couldn't find suitable classes. Is gsr the only option?
>>
>> Jacek
>>
>> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers <pca...@gm...> napisał:
>>> Thanks Ioannis!
>>>
>>> OvernightIndexedCoupon is always backward looking. We model forward
>>> looking term rates using the TermRateIndex class (derived from
>>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>>> other IborIndex - based classes.
>>>
>>> Does that make sense?
>>>
>>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos <qua...@de...> wrote:
>>>> Hi Peter,
>>>>
>>>> Yes. This now makes sense. I was not aware of this formula. Thank you
>>>> for sharing the paper as it helped me understand the details of
>>>> overnight index cap/floor pricing.
>>>>
>>>> Thanks to ORE, I completed a sofr cap pricing for a client and
>>>> everything went very smoothly. So, kudos for the excellent work! I do
>>>> mention of course that the analytics come from ORE/Acadia.
>>>>
>>>> Just parenthetically, I noticed that the
>>>> QuantExt::OvernightIndexedCoupon does not distinguish between forward
>>>> and backward looking term rates, which is fine for linear contracts, but
>>>> not so for caps or swaptions because a backward looking rate exhibits
>>>> higher variance than its forward looking counterpart. Your formulas
>>>> imply that you treat the OvernightIndexedCoupon as if it were backward
>>>> looking. I would be curious to know if you plan to add a corresponding
>>>> boolean flag in the OvernightIndexedCoupon constructor and adjust the
>>>> vol code discussed here to account for both forward and backward looking
>>>> cases.
>>>>
>>>> Ioannis
>>>>
>>>> On 1/5/2023 10:38 AM, Peter Caspers wrote:
>>>>> Hi Ioannis
>>>>>
>>>>> this is a typo, the line should actually be
>>>>>
>>>>>               T += std::pow(fixingEndTime - T, 3.0) /
>>>>> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>>>>>
>>>>> This corresponds to the formula for v_j^B at the end of section 6.3 in
>>>>> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>>>>>
>>>>> We will fix this shortly.
>>>>>
>>>>> Thank you
>>>>> Peter
>>>>>
>>>>> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
>>>>>> Does anyone have a clue on why the statement (found in
>>>>>> blackovernightindexedcouponpricer.cpp)
>>>>>>
>>>>>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
>>>>>> / 3.0;
>>>>>>
>>>>>> is not coded much more simply as
>>>>>>
>>>>>> T +=( fixingEndTime - T ) / 3.0;
>>>>>>
>>>>>> The two variables T and fixingEndTime  are both double.
>>>>>>
>>>>>> I am only asking in case there is some sort of sophisticated trick that
>>>>>> I am missing.
>>>>>>
>>>>>> Ioannis
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>>>> www.avast.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> --
>>>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>>>> www.avast.com
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Qurious finding in ORE code

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

Hi Jacek,

I don't think it is at the moment. Even GSR won't work properly for
OvernightIndexedCoupon.

Thank you
Peter

On Mon, 9 Jan 2023 at 18:08, Jacek Bator <jac...@gm...> wrote:
>
> Hi Peter,
> Is this formula implemented in Quantlib as well? I'm trying to price RFR caps, but couldn't find suitable classes. Is gsr the only option?
>
> Jacek
>
> pon., 9 sty 2023, 17:35 użytkownik Peter Caspers <pca...@gm...> napisał:
>>
>> Thanks Ioannis!
>>
>> OvernightIndexedCoupon is always backward looking. We model forward
>> looking term rates using the TermRateIndex class (derived from
>> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
>> other IborIndex - based classes.
>>
>> Does that make sense?
>>
>> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos <qua...@de...> wrote:
>> >
>> > Hi Peter,
>> >
>> > Yes. This now makes sense. I was not aware of this formula. Thank you
>> > for sharing the paper as it helped me understand the details of
>> > overnight index cap/floor pricing.
>> >
>> > Thanks to ORE, I completed a sofr cap pricing for a client and
>> > everything went very smoothly. So, kudos for the excellent work! I do
>> > mention of course that the analytics come from ORE/Acadia.
>> >
>> > Just parenthetically, I noticed that the
>> > QuantExt::OvernightIndexedCoupon does not distinguish between forward
>> > and backward looking term rates, which is fine for linear contracts, but
>> > not so for caps or swaptions because a backward looking rate exhibits
>> > higher variance than its forward looking counterpart. Your formulas
>> > imply that you treat the OvernightIndexedCoupon as if it were backward
>> > looking. I would be curious to know if you plan to add a corresponding
>> > boolean flag in the OvernightIndexedCoupon constructor and adjust the
>> > vol code discussed here to account for both forward and backward looking
>> > cases.
>> >
>> > Ioannis
>> >
>> > On 1/5/2023 10:38 AM, Peter Caspers wrote:
>> > > Hi Ioannis
>> > >
>> > > this is a typo, the line should actually be
>> > >
>> > >              T += std::pow(fixingEndTime - T, 3.0) /
>> > > std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>> > >
>> > > This corresponds to the formula for v_j^B at the end of section 6.3 in
>> > > https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>> > >
>> > > We will fix this shortly.
>> > >
>> > > Thank you
>> > > Peter
>> > >
>> > > On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
>> > >> Does anyone have a clue on why the statement (found in
>> > >> blackovernightindexedcouponpricer.cpp)
>> > >>
>> > >> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
>> > >> / 3.0;
>> > >>
>> > >> is not coded much more simply as
>> > >>
>> > >> T +=( fixingEndTime - T ) / 3.0;
>> > >>
>> > >> The two variables T and fixingEndTime  are both double.
>> > >>
>> > >> I am only asking in case there is some sort of sophisticated trick that
>> > >> I am missing.
>> > >>
>> > >> Ioannis
>> > >>
>> > >>
>> > >> --
>> > >> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>> > >> www.avast.com
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> QuantLib-users mailing list
>> > >> Qua...@li...
>> > >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> >
>> > --
>> > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>> > www.avast.com
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>

Re: [Quantlib-users] Qurious finding in ORE code

[Jacek B. <jac...@gm...>]

Hi Peter,
Is this formula implemented in Quantlib as well? I'm trying to price RFR
caps, but couldn't find suitable classes. Is gsr the only option?

Jacek

pon., 9 sty 2023, 17:35 użytkownik Peter Caspers <pca...@gm...>
napisał:

> Thanks Ioannis!
>
> OvernightIndexedCoupon is always backward looking. We model forward
> looking term rates using the TermRateIndex class (derived from
> IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
> other IborIndex - based classes.
>
> Does that make sense?
>
> On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos <qua...@de...>
> wrote:
> >
> > Hi Peter,
> >
> > Yes. This now makes sense. I was not aware of this formula. Thank you
> > for sharing the paper as it helped me understand the details of
> > overnight index cap/floor pricing.
> >
> > Thanks to ORE, I completed a sofr cap pricing for a client and
> > everything went very smoothly. So, kudos for the excellent work! I do
> > mention of course that the analytics come from ORE/Acadia.
> >
> > Just parenthetically, I noticed that the
> > QuantExt::OvernightIndexedCoupon does not distinguish between forward
> > and backward looking term rates, which is fine for linear contracts, but
> > not so for caps or swaptions because a backward looking rate exhibits
> > higher variance than its forward looking counterpart. Your formulas
> > imply that you treat the OvernightIndexedCoupon as if it were backward
> > looking. I would be curious to know if you plan to add a corresponding
> > boolean flag in the OvernightIndexedCoupon constructor and adjust the
> > vol code discussed here to account for both forward and backward looking
> > cases.
> >
> > Ioannis
> >
> > On 1/5/2023 10:38 AM, Peter Caspers wrote:
> > > Hi Ioannis
> > >
> > > this is a typo, the line should actually be
> > >
> > >              T += std::pow(fixingEndTime - T, 3.0) /
> > > std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
> > >
> > > This corresponds to the formula for v_j^B at the end of section 6.3 in
> > > https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
> > >
> > > We will fix this shortly.
> > >
> > > Thank you
> > > Peter
> > >
> > > On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <
> qua...@de...> wrote:
> > >> Does anyone have a clue on why the statement (found in
> > >> blackovernightindexedcouponpricer.cpp)
> > >>
> > >> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T,
> 2.0)
> > >> / 3.0;
> > >>
> > >> is not coded much more simply as
> > >>
> > >> T +=( fixingEndTime - T ) / 3.0;
> > >>
> > >> The two variables T and fixingEndTime  are both double.
> > >>
> > >> I am only asking in case there is some sort of sophisticated trick
> that
> > >> I am missing.
> > >>
> > >> Ioannis
> > >>
> > >>
> > >> --
> > >> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> > >> www.avast.com
> > >>
> > >>
> > >> _______________________________________________
> > >> QuantLib-users mailing list
> > >> Qua...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
> > --
> > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> > www.avast.com
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

Re: [Quantlib-users] Qurious finding in ORE code

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

Thanks Ioannis!

OvernightIndexedCoupon is always backward looking. We model forward
looking term rates using the TermRateIndex class (derived from
IborIndex) such as in SofrTerm in conjunction with e.g. IborCoupon or
other IborIndex - based classes.

Does that make sense?

On Fri, 6 Jan 2023 at 18:22, Ioannis Rigopoulos <qua...@de...> wrote:
>
> Hi Peter,
>
> Yes. This now makes sense. I was not aware of this formula. Thank you
> for sharing the paper as it helped me understand the details of
> overnight index cap/floor pricing.
>
> Thanks to ORE, I completed a sofr cap pricing for a client and
> everything went very smoothly. So, kudos for the excellent work! I do
> mention of course that the analytics come from ORE/Acadia.
>
> Just parenthetically, I noticed that the
> QuantExt::OvernightIndexedCoupon does not distinguish between forward
> and backward looking term rates, which is fine for linear contracts, but
> not so for caps or swaptions because a backward looking rate exhibits
> higher variance than its forward looking counterpart. Your formulas
> imply that you treat the OvernightIndexedCoupon as if it were backward
> looking. I would be curious to know if you plan to add a corresponding
> boolean flag in the OvernightIndexedCoupon constructor and adjust the
> vol code discussed here to account for both forward and backward looking
> cases.
>
> Ioannis
>
> On 1/5/2023 10:38 AM, Peter Caspers wrote:
> > Hi Ioannis
> >
> > this is a typo, the line should actually be
> >
> >              T += std::pow(fixingEndTime - T, 3.0) /
> > std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
> >
> > This corresponds to the formula for v_j^B at the end of section 6.3 in
> > https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
> >
> > We will fix this shortly.
> >
> > Thank you
> > Peter
> >
> > On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
> >> Does anyone have a clue on why the statement (found in
> >> blackovernightindexedcouponpricer.cpp)
> >>
> >> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
> >> / 3.0;
> >>
> >> is not coded much more simply as
> >>
> >> T +=( fixingEndTime - T ) / 3.0;
> >>
> >> The two variables T and fixingEndTime  are both double.
> >>
> >> I am only asking in case there is some sort of sophisticated trick that
> >> I am missing.
> >>
> >> Ioannis
> >>
> >>
> >> --
> >> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> >> www.avast.com
> >>
> >>
> >> _______________________________________________
> >> QuantLib-users mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> --
> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> www.avast.com

Re: [Quantlib-users] Aging a swap without changing the curve producing unexpected results

[Arkadiy N. <ark...@gm...>]

As far as I understand, because the inputs into the swap include schedules
(which would change if you want to move everything out), you'd have to
rebuild the swap. You could refactor your script a bit to make the swap
creation a parameterized function (thus making such changes more
streamlined going forward), but that's entirely up to you.

On Wed, Jan 4, 2023 at 1:22 PM Shaun Viguerie <svi...@ve...>
wrote:

> Thank you for the explanation here.   Is there a simple way to push the
> settlement date out on an existing swap once created?  Or would I need to
> create an additional swap?
>
>
>
>
>
> *From:* Arkadiy Naumov <ark...@gm...>
> *Sent:* Monday, December 19, 2022 10:57 PM
> *To:* Shaun Viguerie <svi...@ve...>
> *Cc:* qua...@li...
> *Subject:* Re: [Quantlib-users] Aging a swap without changing the curve
> producing unexpected results
>
>
>
> *This Message originated outside your organization.*
> ------------------------------
>
> Hi Shaun,
>
>
>
> From what I can see in the script, you've moved your evaluation date
> forward, but kept swap settlement the same, so your forward rates that
> drive floating leg cash flows are now different. Before it was a series of
> 3M forwards starting 1Y out, and now it's forwards starting 345 days out.
> In order to keep the cash flows unchanged, you'd need to account for the
> 20-days "roll" down the curve or push the settlement out.
>
>
>
> On Mon, Dec 19, 2022 at 6:14 PM Shaun Viguerie <svi...@ve...>
> wrote:
>
> Hi All,
>
>
>
> First, I want to thank Luigi & the community for all of the work on
> QuantLib.  I’m a new user so apologies if my question is stupid…
>
>
>
> I’ve been trying to get a feel for the mechanics of library—specifically
> around TermStructures and Interest Rate Swaps.     In doing so, I wanted to
> test a base case:
>
>
>
>    - Create a simple YieldCurve instance using a 3M Short Rate future +
>    1Y-10Y Swap Rates
>    - Create a VanillaSwap on top of this structure
>    - Evaluate the NPV of this swap & examine the cashflows
>    - Advance the calendar 10 days [*without changing the curve at all]*
>    - Evaluate the NPV of the swap & examine the cashflows]
>
>
>
> In the above experiment, given that I *am not *changing the curve, I
> would expect the cashflows to remain the same [while the NPVs would
> change].  However, I am unable get this working, despite running through
> several tutorials online (DIMA’s slides, a couple of Luigi’s videos).  I
> have gleaned that this might have something to do with adding fixing days
> to the indices?   But I’m not sure I understand the mechanics of why that
> would be or how I should think about managing fixings as I advance time in
> the library.
>
>
>
> I’m happy to provide more information…. A messy version of the code is
> attached below:
>
>
>
> import pandas as pd
>
> import QuantLib as ql
>
> from QuantLib import *
>
>
>
> def show_cashflows(leg):
>
>     for c in leg:
>
>         print ('%20s | %s | %.4f%%' % (c.date(), c.amount(),
>
>                                       as_coupon(c).rate()*100))
>
>
>
>
>
> calendar = TARGET()
>
>
>
> tddt = pd.to_datetime('today').date()
>
> todaysDate = ql.Date(tddt.day, tddt.month, tddt.year)
>
>
>
> Settings.instance().evaluationDate = todaysDate
>
> settlementDate = calendar.advance(todaysDate, 12, ql.Months)
>
>
>
> # market quotes
>
> deposits = {  (3,Months): 0.047245}
>
>
>
> swaps = {
>
>     (1,Years): 0.05876,
>
>     (2,Years): 0.045986,
>
>     (4,Years): 0.038589,
>
>     (5,Years): 0.036954,
>
>     (6,Years): 0.035925,
>
>     (7,Years): 0.0352,
>
>     (8,Years): 0.034683,
>
>     (9,Years): 0.03437,
>
>     (10,Years): .034186
>
> }
>
>
>
>
>
> # convert them to Quote objects
>
> for n,unit in deposits.keys():
>
>     deposits[(n,unit)] = SimpleQuote(deposits[(n,unit)])
>
> for n,unit in swaps.keys():
>
>     swaps[(n,unit)] = SimpleQuote(swaps[(n,unit)])
>
>
>
>
>
> # build rate helpers
>
> dayCounter = Actual360()
>
> settlementDays = 2
>
> depositHelpers = [ DepositRateHelper(QuoteHandle(deposits[(n,unit)]),
>
>                                      Period(n,unit), settlementDays,
>
>                                      calendar, ModifiedFollowing,
>
>                                      False, dayCounter)
>
>                    for n, unit in [(3,Months) ]]
>
>
>
>
>
> swapHelpers = [ SwapRateHelper(QuoteHandle(swaps[(n,unit)]),
>
>                                Period(n,unit), calendar,
>
>                                Annual, Unadjusted,
>
>                                Actual360(), Euribor6M())
>
>                 for n, unit in swaps.keys() ]
>
>
>
>
>
> # term-structure construction
>
> helpers = depositHelpers + swapHelpers
>
>
>
> # term structure handles...why do I need both?
>
> discountTermStructure = RelinkableYieldTermStructureHandle()
>
> forecastTermStructure = RelinkableYieldTermStructureHandle()
>
>
>
> depoSwapCurve = PiecewiseLogCubicDiscount(settlementDays, TARGET(),
> helpers, Actual360())
>
> depoSwapCurve.enableExtrapolation()
>
>
>
> swapEngine = DiscountingSwapEngine(discountTermStructure)
>
>
>
> # 5Y Swap
>
> nominal = 1000000
>
> maturity1 = calendar.advance(settlementDate,5,Years)
>
>
>
>
>
> fixedRate = 0.036954
>
>
>
> spread = 0.0
>
>
>
> index = ql.USDLibor(ql.Period(3, ql.Months), forecastTermStructure)
>
>
>
> floatingLegAdjustment = ModifiedFollowing
>
> floatingLegDayCounter = index.dayCounter()
>
>
>
> fixedSchedule1 = Schedule(settlementDate, maturity1,
>
>                          Period(1, Years), calendar,
>
>                          Unadjusted, Unadjusted,
>
>                          DateGeneration.Forward, False)
>
> floatingSchedule1 = Schedule(settlementDate, maturity1,
>
>                             Period(6,Months), calendar,
>
>                             ModifiedFollowing, ModifiedFollowing,
>
>                             DateGeneration.Forward, False)
>
>
>
> # when I create the swap using this method, the cashflows remain fixed
> upon advancing the day
>
> spot1 = VanillaSwap(VanillaSwap.Receiver, nominal,
>
>                    fixedSchedule1, fixedRate, Actual360(),
>
>                    floatingSchedule1, index, spread,
>
>                    floatingLegDayCounter)
>
>
>
>
>
> spot1.setPricingEngine(swapEngine)
>
> discountTermStructure.linkTo(depoSwapCurve)
>
> forecastTermStructure.linkTo(depoSwapCurve)
>
>
>
>
>
> Settings.instance().evaluationDate = todaysDate
>
> print ('Fair Rate: {}'.format(spot1.fairRate()))
>
> print('NPV: {}'.format(spot1.NPV()))
>
> print('fixed cashflows:')
>
> show_cashflows(spot1.fixedLeg())
>
> print('floating cashflows:')
>
> show_cashflows(spot1.floatingLeg())
>
>
>
> ## AFTER DOING THIS THE FLOATING CASHFLOWS CHANGE AND I WOULD NOT EXPECT
> THEM TO
>
>
>
> Settings.instance().evaluationDate = calendar.advance(todaysDate, 20, Days)
>
> print (spot1.fairRate())
>
> print(spot1.NPV())
>
> print ('Fair Rate: {}'.format(spot1.fairRate()))
>
> print('NPV: {}'.format(spot1.NPV()))
>
> print('fixed cashflows:')
>
> show_cashflows(spot1.fixedLeg())
>
> print('floating cashflows:')
>
> show_cashflows(spot1.floatingLeg())
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>

Re: [Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Hi Peter,

Yes. This now makes sense. I was not aware of this formula. Thank you 
for sharing the paper as it helped me understand the details of 
overnight index cap/floor pricing.

Thanks to ORE, I completed a sofr cap pricing for a client and 
everything went very smoothly. So, kudos for the excellent work! I do 
mention of course that the analytics come from ORE/Acadia.

Just parenthetically, I noticed that the 
QuantExt::OvernightIndexedCoupon does not distinguish between forward 
and backward looking term rates, which is fine for linear contracts, but 
not so for caps or swaptions because a backward looking rate exhibits 
higher variance than its forward looking counterpart. Your formulas 
imply that you treat the OvernightIndexedCoupon as if it were backward 
looking. I would be curious to know if you plan to add a corresponding 
boolean flag in the OvernightIndexedCoupon constructor and adjust the 
vol code discussed here to account for both forward and backward looking 
cases.

Ioannis

On 1/5/2023 10:38 AM, Peter Caspers wrote:
> Hi Ioannis
>
> this is a typo, the line should actually be
>
>              T += std::pow(fixingEndTime - T, 3.0) /
> std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;
>
> This corresponds to the formula for v_j^B at the end of section 6.3 in
> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.
>
> We will fix this shortly.
>
> Thank you
> Peter
>
> On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
>> Does anyone have a clue on why the statement (found in
>> blackovernightindexedcouponpricer.cpp)
>>
>> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
>> / 3.0;
>>
>> is not coded much more simply as
>>
>> T +=( fixingEndTime - T ) / 3.0;
>>
>> The two variables T and fixingEndTime  are both double.
>>
>> I am only asking in case there is some sort of sophisticated trick that
>> I am missing.
>>
>> Ioannis
>>
>>
>> --
>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>> www.avast.com
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Problem with LocalVol and Piecewise Time Dependent Heston processes

[Dan V. <dan...@gm...>]

Thank you very much Jack for this clarification.
Unfortunately for us the Andreasen Huge yields very poor results on a well
behaved SPX surface.
As a consequence we will have to get out of the entire QL ecosystem as
nothing beyond a vanilla call and put can be priced.
Thanks for your help again.

On Tue, Jan 3, 2023 at 9:39 PM Jack G <jac...@gm...> wrote:

> Hi Dan,
>
> Looking over my notes, here is what we did:
>
> - Calibrated a local vol surface within QL using Andreasen Huge. This
> didn't cause problems for us but the vol surfaces were quite well behaved -
> we were using FX data from Bloomberg, the main data issues were around FX
> quoting conventions as I recall
> - Fitted raw Heston to the data (we didn't use PWC Heston in the end as
> discussed previously)
> - Calibrated a leverage function (note the AH instantaneous vol surface
> was used here not the surface itself), I see we tried both FD and MC
> calibrations, and calibrated mixing factors too to a selection of DNTs (I
> recall there was a bug in one of the QL calibrations which was ignoring
> mixing factor that we fixed around that time)
> - Tested the leverage function against vanillas using FdHestonVanillaEngine
> which admits a leverage function, and tested various MC prices using HestonSLVProcess,
> both of these engines do not rely on the Andraesen Huge calibrated object
> directly, only on the leverage function calibrated from it
>
> All the best,
> Jack
>
> On Sat, Dec 31, 2022 at 12:16 AM Dan VolPM <dan...@gm...> wrote:
>
>> Hi Jack,
>> You mean that you built both your own LV surface outside of QL (since QL
>> won't let you build a correct one) as well as calibrating the PTD Heston
>> outside of QL ?
>> Then you fed the 2 to QL to get the leverage function and from then on
>> stayed in the QL ecosystem ?
>> Thanks
>> Dan
>>
>> On Fri, Dec 30, 2022 at 8:24 AM Jack G <jac...@gm...> wrote:
>>
>>> Hi Dan,
>>>
>>> We went with SLV in the end using plain fixed-parameter Heston and a
>>> leverage function (using the QuantLib calibration and path generation code).
>>>
>>> Best,
>>> Jack
>>>
>>> On Thu, Dec 29, 2022 at 8:01 AM Dan VolPM <dan...@gm...> wrote:
>>>
>>>> Thank you jack.
>>>> What direction did you end up taking to price non vanilla products
>>>> using QL ?
>>>>
>>>> On Mon, Dec 19, 2022 at 7:24 PM Jack G <jac...@gm...>
>>>> wrote:
>>>>
>>>>> Hi Dan,
>>>>>
>>>>> Just for reference on the PTD Heston, adding a path generator for PTD
>>>>> Heston was something I looked at during a side project a year or so ago -
>>>>> there is some code in an abandoned pull request here but it's fairly
>>>>> horrible: https://github.com/lballabio/QuantLib/pull/1185/files
>>>>>
>>>>> In the end I found exactly the problems you have mentioned for PTD
>>>>> Heston - hard and slow to calibrate, and I wasn't getting much convergence
>>>>> from the MC prices for anything beyond vanillas. A lot of this is because
>>>>> several of the extremely useful optimizations for Heston path generation
>>>>> stop working nicely in PTD Heston.
>>>>>
>>>>> Best luck with the project,
>>>>> Jack
>>>>>
>>>>> On Tue, 20 Dec 2022, 01:24 Dan VolPM, <dan...@gm...> wrote:
>>>>>
>>>>>> Hello experts,
>>>>>>
>>>>>> Has anyone been able to price any product in monte carlo (generating
>>>>>> path via the GaussianMultiPathGenerator) using either a local vol surface
>>>>>> or a piecewise Heston ?
>>>>>> I should mention we used python.
>>>>>>
>>>>>> *The problems with LocalVol is:*
>>>>>> - Only the AndreasenHugeVolatility does not break when generating
>>>>>> paths, however there is such a loss of information in the process of
>>>>>> building it that the prices generated are extremely far from the
>>>>>> calibrating vanillas
>>>>>> - Whenever we use our (smoothed and cleaned) BlackVarianceSurface and
>>>>>> generate paths with it, it is converted into a localvol surface under the
>>>>>> cover which is perfect for path generation BUT it is virtually impossible
>>>>>> to actually get paths that don't break on "arbitrages". I use the quote
>>>>>> there  for arbitrage because the test used is so granular that converting
>>>>>> any kind of real life market surface will fail (I'm not talking here about
>>>>>> the 4x4 matrices that we all use for examples but rather a huge SPX surface
>>>>>> with tons of strikes and maturities). Even an SVI failed at that which is
>>>>>> telling me either we do something very wrong or the falling var and fly
>>>>>> testing is just too granular.
>>>>>>
>>>>>> => this leaves us stuck unable to price any non standard payoff in LV
>>>>>>
>>>>>> *The problem with PTD Heston is:*
>>>>>> - It takes forever to calibrate and still has a pretty poor quality
>>>>>> of fit
>>>>>> - there is no way to build a PTDHeston process like there is for
>>>>>> regular Heston. Consequently building paths is just impossible.
>>>>>>
>>>>>> Is there a different way to go about pricing non standard payoffs
>>>>>> using one of these 2 methods ?
>>>>>> Happy to hear from someone who can actually make it work.
>>>>>>
>>>>>> Any help would be greatly appreciated.
>>>>>> Thank you
>>>>>>
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>

Re: [Quantlib-users] Qurious finding in ORE code

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

Hi Ioannis

this is a typo, the line should actually be

            T += std::pow(fixingEndTime - T, 3.0) /
std::pow(fixingEndTime - fixingStartTime, 2.0) / 3.0;

This corresponds to the formula for v_j^B at the end of section 6.3 in
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3330240.

We will fix this shortly.

Thank you
Peter

On Wed, 4 Jan 2023 at 19:13, Ioannis Rigopoulos <qua...@de...> wrote:
>
> Does anyone have a clue on why the statement (found in
> blackovernightindexedcouponpricer.cpp)
>
> T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0)
> / 3.0;
>
> is not coded much more simply as
>
> T +=( fixingEndTime - T ) / 3.0;
>
> The two variables T and fixingEndTime  are both double.
>
> I am only asking in case there is some sort of sophisticated trick that
> I am missing.
>
> Ioannis
>
>
> --
> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> www.avast.com
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Aging a swap without changing the curve producing unexpected results

[Shaun V. <svi...@ve...>]

Thank you for the explanation here.   Is there a simple way to push the settlement date out on an existing swap once created?  Or would I need to create an additional swap?


From: Arkadiy Naumov <ark...@gm...>
Sent: Monday, December 19, 2022 10:57 PM
To: Shaun Viguerie <svi...@ve...>
Cc: qua...@li...
Subject: Re: [Quantlib-users] Aging a swap without changing the curve producing unexpected results

This Message originated outside your organization.
________________________________
Hi Shaun,

From what I can see in the script, you've moved your evaluation date forward, but kept swap settlement the same, so your forward rates that drive floating leg cash flows are now different. Before it was a series of 3M forwards starting 1Y out, and now it's forwards starting 345 days out. In order to keep the cash flows unchanged, you'd need to account for the 20-days "roll" down the curve or push the settlement out.

On Mon, Dec 19, 2022 at 6:14 PM Shaun Viguerie <svi...@ve...<mailto:svi...@ve...>> wrote:
Hi All,

First, I want to thank Luigi & the community for all of the work on QuantLib.  I’m a new user so apologies if my question is stupid…

I’ve been trying to get a feel for the mechanics of library—specifically around TermStructures and Interest Rate Swaps.     In doing so, I wanted to test a base case:


  *   Create a simple YieldCurve instance using a 3M Short Rate future + 1Y-10Y Swap Rates
  *   Create a VanillaSwap on top of this structure
  *   Evaluate the NPV of this swap & examine the cashflows
  *   Advance the calendar 10 days [without changing the curve at all]
  *   Evaluate the NPV of the swap & examine the cashflows]

In the above experiment, given that I am not changing the curve, I would expect the cashflows to remain the same [while the NPVs would change].  However, I am unable get this working, despite running through several tutorials online (DIMA’s slides, a couple of Luigi’s videos).  I have gleaned that this might have something to do with adding fixing days to the indices?   But I’m not sure I understand the mechanics of why that would be or how I should think about managing fixings as I advance time in the library.

I’m happy to provide more information…. A messy version of the code is attached below:

import pandas as pd
import QuantLib as ql
from QuantLib import *

def show_cashflows(leg):
    for c in leg:
        print ('%20s | %s | %.4f%%' % (c.date(), c.amount(),
                                      as_coupon(c).rate()*100))


calendar = TARGET()

tddt = pd.to_datetime('today').date()
todaysDate = ql.Date(tddt.day, tddt.month, tddt.year)

Settings.instance().evaluationDate = todaysDate
settlementDate = calendar.advance(todaysDate, 12, ql.Months)

# market quotes
deposits = {  (3,Months): 0.047245}

swaps = {
    (1,Years): 0.05876,
    (2,Years): 0.045986,
    (4,Years): 0.038589,
    (5,Years): 0.036954,
    (6,Years): 0.035925,
    (7,Years): 0.0352,
    (8,Years): 0.034683,
    (9,Years): 0.03437,
    (10,Years): .034186
}


# convert them to Quote objects
for n,unit in deposits.keys():
    deposits[(n,unit)] = SimpleQuote(deposits[(n,unit)])
for n,unit in swaps.keys():
    swaps[(n,unit)] = SimpleQuote(swaps[(n,unit)])


# build rate helpers
dayCounter = Actual360()
settlementDays = 2
depositHelpers = [ DepositRateHelper(QuoteHandle(deposits[(n,unit)]),
                                     Period(n,unit), settlementDays,
                                     calendar, ModifiedFollowing,
                                     False, dayCounter)
                   for n, unit in [(3,Months) ]]


swapHelpers = [ SwapRateHelper(QuoteHandle(swaps[(n,unit)]),
                               Period(n,unit), calendar,
                               Annual, Unadjusted,
                               Actual360(), Euribor6M())
                for n, unit in swaps.keys() ]


# term-structure construction
helpers = depositHelpers + swapHelpers

# term structure handles...why do I need both?
discountTermStructure = RelinkableYieldTermStructureHandle()
forecastTermStructure = RelinkableYieldTermStructureHandle()

depoSwapCurve = PiecewiseLogCubicDiscount(settlementDays, TARGET(), helpers, Actual360())
depoSwapCurve.enableExtrapolation()

swapEngine = DiscountingSwapEngine(discountTermStructure)

# 5Y Swap
nominal = 1000000
maturity1 = calendar.advance(settlementDate,5,Years)


fixedRate = 0.036954

spread = 0.0

index = ql.USDLibor(ql.Period(3, ql.Months), forecastTermStructure)

floatingLegAdjustment = ModifiedFollowing
floatingLegDayCounter = index.dayCounter()

fixedSchedule1 = Schedule(settlementDate, maturity1,
                         Period(1, Years), calendar,
                         Unadjusted, Unadjusted,
                         DateGeneration.Forward, False)
floatingSchedule1 = Schedule(settlementDate, maturity1,
                            Period(6,Months), calendar,
                            ModifiedFollowing, ModifiedFollowing,
                            DateGeneration.Forward, False)

# when I create the swap using this method, the cashflows remain fixed upon advancing the day
spot1 = VanillaSwap(VanillaSwap.Receiver, nominal,
                   fixedSchedule1, fixedRate, Actual360(),
                   floatingSchedule1, index, spread,
                   floatingLegDayCounter)


spot1.setPricingEngine(swapEngine)
discountTermStructure.linkTo(depoSwapCurve)
forecastTermStructure.linkTo(depoSwapCurve)


Settings.instance().evaluationDate = todaysDate
print ('Fair Rate: {}'.format(spot1.fairRate()))
print('NPV: {}'.format(spot1.NPV()))
print('fixed cashflows:')
show_cashflows(spot1.fixedLeg())
print('floating cashflows:')
show_cashflows(spot1.floatingLeg())

## AFTER DOING THIS THE FLOATING CASHFLOWS CHANGE AND I WOULD NOT EXPECT THEM TO

Settings.instance().evaluationDate = calendar.advance(todaysDate, 20, Days)
print (spot1.fairRate())
print(spot1.NPV())
print ('Fair Rate: {}'.format(spot1.fairRate()))
print('NPV: {}'.format(spot1.NPV()))
print('fixed cashflows:')
show_cashflows(spot1.fixedLeg())
print('floating cashflows:')
show_cashflows(spot1.floatingLeg())
_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-users] Qurious finding in ORE code

[Ioannis R. <qua...@de...>]

Does anyone have a clue on why the statement (found in 
blackovernightindexedcouponpricer.cpp)

T += std::pow(fixingEndTime - T, 3.0) / std::pow(fixingEndTime - T, 2.0) 
/ 3.0;

is not coded much more simply as

T +=( fixingEndTime - T ) / 3.0;

The two variables T and fixingEndTime  are both double.

I am only asking in case there is some sort of sophisticated trick that 
I am missing.

Ioannis


-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Problem with LocalVol and Piecewise Time Dependent Heston processes

[Jack G <jac...@gm...>]

Hi Dan,

Looking over my notes, here is what we did:

- Calibrated a local vol surface within QL using Andreasen Huge. This
didn't cause problems for us but the vol surfaces were quite well behaved -
we were using FX data from Bloomberg, the main data issues were around FX
quoting conventions as I recall
- Fitted raw Heston to the data (we didn't use PWC Heston in the end as
discussed previously)
- Calibrated a leverage function (note the AH instantaneous vol surface was
used here not the surface itself), I see we tried both FD and MC
calibrations, and calibrated mixing factors too to a selection of DNTs (I
recall there was a bug in one of the QL calibrations which was ignoring
mixing factor that we fixed around that time)
- Tested the leverage function against vanillas using FdHestonVanillaEngine
which admits a leverage function, and tested various MC prices using
HestonSLVProcess,
both of these engines do not rely on the Andraesen Huge calibrated object
directly, only on the leverage function calibrated from it

All the best,
Jack

On Sat, Dec 31, 2022 at 12:16 AM Dan VolPM <dan...@gm...> wrote:

> Hi Jack,
> You mean that you built both your own LV surface outside of QL (since QL
> won't let you build a correct one) as well as calibrating the PTD Heston
> outside of QL ?
> Then you fed the 2 to QL to get the leverage function and from then on
> stayed in the QL ecosystem ?
> Thanks
> Dan
>
> On Fri, Dec 30, 2022 at 8:24 AM Jack G <jac...@gm...> wrote:
>
>> Hi Dan,
>>
>> We went with SLV in the end using plain fixed-parameter Heston and a
>> leverage function (using the QuantLib calibration and path generation code).
>>
>> Best,
>> Jack
>>
>> On Thu, Dec 29, 2022 at 8:01 AM Dan VolPM <dan...@gm...> wrote:
>>
>>> Thank you jack.
>>> What direction did you end up taking to price non vanilla products using
>>> QL ?
>>>
>>> On Mon, Dec 19, 2022 at 7:24 PM Jack G <jac...@gm...> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> Just for reference on the PTD Heston, adding a path generator for PTD
>>>> Heston was something I looked at during a side project a year or so ago -
>>>> there is some code in an abandoned pull request here but it's fairly
>>>> horrible: https://github.com/lballabio/QuantLib/pull/1185/files
>>>>
>>>> In the end I found exactly the problems you have mentioned for PTD
>>>> Heston - hard and slow to calibrate, and I wasn't getting much convergence
>>>> from the MC prices for anything beyond vanillas. A lot of this is because
>>>> several of the extremely useful optimizations for Heston path generation
>>>> stop working nicely in PTD Heston.
>>>>
>>>> Best luck with the project,
>>>> Jack
>>>>
>>>> On Tue, 20 Dec 2022, 01:24 Dan VolPM, <dan...@gm...> wrote:
>>>>
>>>>> Hello experts,
>>>>>
>>>>> Has anyone been able to price any product in monte carlo (generating
>>>>> path via the GaussianMultiPathGenerator) using either a local vol surface
>>>>> or a piecewise Heston ?
>>>>> I should mention we used python.
>>>>>
>>>>> *The problems with LocalVol is:*
>>>>> - Only the AndreasenHugeVolatility does not break when generating
>>>>> paths, however there is such a loss of information in the process of
>>>>> building it that the prices generated are extremely far from the
>>>>> calibrating vanillas
>>>>> - Whenever we use our (smoothed and cleaned) BlackVarianceSurface and
>>>>> generate paths with it, it is converted into a localvol surface under the
>>>>> cover which is perfect for path generation BUT it is virtually impossible
>>>>> to actually get paths that don't break on "arbitrages". I use the quote
>>>>> there  for arbitrage because the test used is so granular that converting
>>>>> any kind of real life market surface will fail (I'm not talking here about
>>>>> the 4x4 matrices that we all use for examples but rather a huge SPX surface
>>>>> with tons of strikes and maturities). Even an SVI failed at that which is
>>>>> telling me either we do something very wrong or the falling var and fly
>>>>> testing is just too granular.
>>>>>
>>>>> => this leaves us stuck unable to price any non standard payoff in LV
>>>>>
>>>>> *The problem with PTD Heston is:*
>>>>> - It takes forever to calibrate and still has a pretty poor quality of
>>>>> fit
>>>>> - there is no way to build a PTDHeston process like there is for
>>>>> regular Heston. Consequently building paths is just impossible.
>>>>>
>>>>> Is there a different way to go about pricing non standard payoffs
>>>>> using one of these 2 methods ?
>>>>> Happy to hear from someone who can actually make it work.
>>>>>
>>>>> Any help would be greatly appreciated.
>>>>> Thank you
>>>>>
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>

Re: [Quantlib-users] Problem with LocalVol and Piecewise Time Dependent Heston processes

[Dan V. <dan...@gm...>]

Hi Jack,
You mean that you built both your own LV surface outside of QL (since QL
won't let you build a correct one) as well as calibrating the PTD Heston
outside of QL ?
Then you fed the 2 to QL to get the leverage function and from then on
stayed in the QL ecosystem ?
Thanks
Dan

On Fri, Dec 30, 2022 at 8:24 AM Jack G <jac...@gm...> wrote:

> Hi Dan,
>
> We went with SLV in the end using plain fixed-parameter Heston and a
> leverage function (using the QuantLib calibration and path generation code).
>
> Best,
> Jack
>
> On Thu, Dec 29, 2022 at 8:01 AM Dan VolPM <dan...@gm...> wrote:
>
>> Thank you jack.
>> What direction did you end up taking to price non vanilla products using
>> QL ?
>>
>> On Mon, Dec 19, 2022 at 7:24 PM Jack G <jac...@gm...> wrote:
>>
>>> Hi Dan,
>>>
>>> Just for reference on the PTD Heston, adding a path generator for PTD
>>> Heston was something I looked at during a side project a year or so ago -
>>> there is some code in an abandoned pull request here but it's fairly
>>> horrible: https://github.com/lballabio/QuantLib/pull/1185/files
>>>
>>> In the end I found exactly the problems you have mentioned for PTD
>>> Heston - hard and slow to calibrate, and I wasn't getting much convergence
>>> from the MC prices for anything beyond vanillas. A lot of this is because
>>> several of the extremely useful optimizations for Heston path generation
>>> stop working nicely in PTD Heston.
>>>
>>> Best luck with the project,
>>> Jack
>>>
>>> On Tue, 20 Dec 2022, 01:24 Dan VolPM, <dan...@gm...> wrote:
>>>
>>>> Hello experts,
>>>>
>>>> Has anyone been able to price any product in monte carlo (generating
>>>> path via the GaussianMultiPathGenerator) using either a local vol surface
>>>> or a piecewise Heston ?
>>>> I should mention we used python.
>>>>
>>>> *The problems with LocalVol is:*
>>>> - Only the AndreasenHugeVolatility does not break when generating
>>>> paths, however there is such a loss of information in the process of
>>>> building it that the prices generated are extremely far from the
>>>> calibrating vanillas
>>>> - Whenever we use our (smoothed and cleaned) BlackVarianceSurface and
>>>> generate paths with it, it is converted into a localvol surface under the
>>>> cover which is perfect for path generation BUT it is virtually impossible
>>>> to actually get paths that don't break on "arbitrages". I use the quote
>>>> there  for arbitrage because the test used is so granular that converting
>>>> any kind of real life market surface will fail (I'm not talking here about
>>>> the 4x4 matrices that we all use for examples but rather a huge SPX surface
>>>> with tons of strikes and maturities). Even an SVI failed at that which is
>>>> telling me either we do something very wrong or the falling var and fly
>>>> testing is just too granular.
>>>>
>>>> => this leaves us stuck unable to price any non standard payoff in LV
>>>>
>>>> *The problem with PTD Heston is:*
>>>> - It takes forever to calibrate and still has a pretty poor quality of
>>>> fit
>>>> - there is no way to build a PTDHeston process like there is for
>>>> regular Heston. Consequently building paths is just impossible.
>>>>
>>>> Is there a different way to go about pricing non standard payoffs using
>>>> one of these 2 methods ?
>>>> Happy to hear from someone who can actually make it work.
>>>>
>>>> Any help would be greatly appreciated.
>>>> Thank you
>>>>
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>

Re: [Quantlib-users] Problem with LocalVol and Piecewise Time Dependent Heston processes

[Jack G <jac...@gm...>]

Hi Dan,

We went with SLV in the end using plain fixed-parameter Heston and a
leverage function (using the QuantLib calibration and path generation code).

Best,
Jack

On Thu, Dec 29, 2022 at 8:01 AM Dan VolPM <dan...@gm...> wrote:

> Thank you jack.
> What direction did you end up taking to price non vanilla products using
> QL ?
>
> On Mon, Dec 19, 2022 at 7:24 PM Jack G <jac...@gm...> wrote:
>
>> Hi Dan,
>>
>> Just for reference on the PTD Heston, adding a path generator for PTD
>> Heston was something I looked at during a side project a year or so ago -
>> there is some code in an abandoned pull request here but it's fairly
>> horrible: https://github.com/lballabio/QuantLib/pull/1185/files
>>
>> In the end I found exactly the problems you have mentioned for PTD Heston
>> - hard and slow to calibrate, and I wasn't getting much convergence from
>> the MC prices for anything beyond vanillas. A lot of this is because
>> several of the extremely useful optimizations for Heston path generation
>> stop working nicely in PTD Heston.
>>
>> Best luck with the project,
>> Jack
>>
>> On Tue, 20 Dec 2022, 01:24 Dan VolPM, <dan...@gm...> wrote:
>>
>>> Hello experts,
>>>
>>> Has anyone been able to price any product in monte carlo (generating
>>> path via the GaussianMultiPathGenerator) using either a local vol surface
>>> or a piecewise Heston ?
>>> I should mention we used python.
>>>
>>> *The problems with LocalVol is:*
>>> - Only the AndreasenHugeVolatility does not break when generating paths,
>>> however there is such a loss of information in the process of building it
>>> that the prices generated are extremely far from the calibrating vanillas
>>> - Whenever we use our (smoothed and cleaned) BlackVarianceSurface and
>>> generate paths with it, it is converted into a localvol surface under the
>>> cover which is perfect for path generation BUT it is virtually impossible
>>> to actually get paths that don't break on "arbitrages". I use the quote
>>> there  for arbitrage because the test used is so granular that converting
>>> any kind of real life market surface will fail (I'm not talking here about
>>> the 4x4 matrices that we all use for examples but rather a huge SPX surface
>>> with tons of strikes and maturities). Even an SVI failed at that which is
>>> telling me either we do something very wrong or the falling var and fly
>>> testing is just too granular.
>>>
>>> => this leaves us stuck unable to price any non standard payoff in LV
>>>
>>> *The problem with PTD Heston is:*
>>> - It takes forever to calibrate and still has a pretty poor quality of
>>> fit
>>> - there is no way to build a PTDHeston process like there is for regular
>>> Heston. Consequently building paths is just impossible.
>>>
>>> Is there a different way to go about pricing non standard payoffs using
>>> one of these 2 methods ?
>>> Happy to hear from someone who can actually make it work.
>>>
>>> Any help would be greatly appreciated.
>>> Thank you
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Problem with LocalVol and Piecewise Time Dependent Heston processes

[Dan V. <dan...@gm...>]

Thank you jack.
What direction did you end up taking to price non vanilla products using QL
?

On Mon, Dec 19, 2022 at 7:24 PM Jack G <jac...@gm...> wrote:

> Hi Dan,
>
> Just for reference on the PTD Heston, adding a path generator for PTD
> Heston was something I looked at during a side project a year or so ago -
> there is some code in an abandoned pull request here but it's fairly
> horrible: https://github.com/lballabio/QuantLib/pull/1185/files
>
> In the end I found exactly the problems you have mentioned for PTD Heston
> - hard and slow to calibrate, and I wasn't getting much convergence from
> the MC prices for anything beyond vanillas. A lot of this is because
> several of the extremely useful optimizations for Heston path generation
> stop working nicely in PTD Heston.
>
> Best luck with the project,
> Jack
>
> On Tue, 20 Dec 2022, 01:24 Dan VolPM, <dan...@gm...> wrote:
>
>> Hello experts,
>>
>> Has anyone been able to price any product in monte carlo (generating path
>> via the GaussianMultiPathGenerator) using either a local vol surface or a
>> piecewise Heston ?
>> I should mention we used python.
>>
>> *The problems with LocalVol is:*
>> - Only the AndreasenHugeVolatility does not break when generating paths,
>> however there is such a loss of information in the process of building it
>> that the prices generated are extremely far from the calibrating vanillas
>> - Whenever we use our (smoothed and cleaned) BlackVarianceSurface and
>> generate paths with it, it is converted into a localvol surface under the
>> cover which is perfect for path generation BUT it is virtually impossible
>> to actually get paths that don't break on "arbitrages". I use the quote
>> there  for arbitrage because the test used is so granular that converting
>> any kind of real life market surface will fail (I'm not talking here about
>> the 4x4 matrices that we all use for examples but rather a huge SPX surface
>> with tons of strikes and maturities). Even an SVI failed at that which is
>> telling me either we do something very wrong or the falling var and fly
>> testing is just too granular.
>>
>> => this leaves us stuck unable to price any non standard payoff in LV
>>
>> *The problem with PTD Heston is:*
>> - It takes forever to calibrate and still has a pretty poor quality of fit
>> - there is no way to build a PTDHeston process like there is for regular
>> Heston. Consequently building paths is just impossible.
>>
>> Is there a different way to go about pricing non standard payoffs using
>> one of these 2 methods ?
>> Happy to hear from someone who can actually make it work.
>>
>> Any help would be greatly appreciated.
>> Thank you
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>