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
>>>>
>