ForecastFixing issue - option paying InArrears
Locked
ForecastFixing issue - option paying InArrears
 
|
Hello, Facing an issue with IborIndex::forecastFixing(...) function - <root>\ql\indexes\iborindex.cpp. What is the difference between 'fixingValueDate' and 'fixingDate' [QLib v1.1 variable names]
We are using QLib 1.1 - but have compared the functionality in v1.4 as well - but no business logic has changed. Only that v1.4 enhances the error catching (to prevent a 0/0) and it is more modularized.
Business case: Trying to price an Option-let (Caplet / Floorlet) which is Fixed in *Arrears*. We pass, the fixing days as '2 business days prior' during the IborLeg formation.
[This can be simulated by any floating rate instrument which requires a forecasted fixing] During the evaluation of Option via the pricing engine, the fixing_date is returned as 2 days prior to maturity of the leg.
Since, the fixing_rate is in the future, it has to be forecasted. It ends up in the above function. We believe there is a bug in calculation of period between fixing_value_date and end_value_date. [QLib v1.4 variable names inside flower braces{}]
Basically, in the function, this turns out to be zero. The reason being, the passed in (parameter) fixing_dateis converted to fixing_value_date {d1} - via the function valueDate. valueDate function, 'advances' the fixing_date by fixing_days (which is 2) to return the mautrity date of the option-let.
The end_value_date {d2} would turn out to be maturity date. Therefore it is zero. This is solved, by choosing to calculate the term between unaltered fixing_date and end_date.
The discount factors would be different (depending on the curve) and forecast fixing would be generated. Have tried to search the forums with 'forecastFixing' but have not found any relevant material.
Would be glad if someone pointed out any information. I will raise this as a bug - for now, but would be glad to stand corrected - and learn the right usage. Thanks Pavan M ------------------------------------------------------------------------------ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hi Pavan,
here is a simple example using an in arrears ibor coupon https://gist.github.com/pcaspers/f8d0500b4852ae94c32f do you see the problem you describe there, too ? Or can you post some code that produces your problem ? best regards Peter On 19 August 2014 11:57, Pavan Mandalkar <[hidden email]> wrote: > Hello, > > Facing an issue with IborIndex::forecastFixing(...) function - > <root>\ql\indexes\iborindex.cpp. > What is the difference between 'fixingValueDate' and 'fixingDate' [QLib v1.1 > variable names] > > We are using QLib 1.1 - but have compared the functionality in v1.4 as well > - but no business logic has changed. > Only that v1.4 enhances the error catching (to prevent a 0/0) and it is more > modularized. > > Business case: > Trying to price an Option-let (Caplet / Floorlet) which is Fixed in > *Arrears*. We pass, the fixing days as '2 business days prior' during the > IborLeg formation. > [This can be simulated by any floating rate instrument which requires a > forecasted fixing] > During the evaluation of Option via the pricing engine, the fixing_date is > returned as 2 days prior to maturity of the leg. > Since, the fixing_rate is in the future, it has to be forecasted. It ends up > in the above function. > > We believe there is a bug in calculation of period between fixing_value_date > and end_value_date. [QLib v1.4 variable names inside flower braces{}] > Basically, in the function, this turns out to be zero. The reason being, the > passed in (parameter) fixing_dateis converted to fixing_value_date {d1} - > via the function valueDate. > valueDate function, 'advances' the fixing_date by fixing_days (which is 2) > to return the mautrity date of the option-let. > The end_value_date {d2} would turn out to be maturity date. > Therefore it is zero. > > This is solved, by choosing to calculate the term between unaltered > fixing_date and end_date. > The discount factors would be different (depending on the curve) and > forecast fixing would be generated. > > Have tried to search the forums with 'forecastFixing' but have not found any > relevant material. > Would be glad if someone pointed out any information. > I will raise this as a bug - for now, but would be glad to stand corrected - > and learn the right usage. > > > Thanks > Pavan M > > ------------------------------------------------------------------------------ > > _______________________________________________ > QuantLib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hello Peter, Thanks for you patience on this; we were able to reproduce the issue with your simple code both in v1.1 and v1.4. Borrowing writing from my previous mail:
The way we interpret the 'in arrears' option to work is that the actual fixing has to be forecasted 2 (or appropriately specified prior-business-days) days before maturity. Therefore the fixing period should not be zero; in the example supplied we see that is always turns out to be zero - when the 'fixingdate' is advanced to 'fixingValueDate' which will be same as 'endValueDate'.
I have added the (image of) code changes we had to perform to get the code working; kindly do review and let us know your thoughts. Thanks Pavan M On Wed, Aug 20, 2014 at 3:07 PM, Peter Caspers <[hidden email]> wrote: Hi Pavan, ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hi Pavan,
I think the current QuantLib code is correct, the forward rate needs to be estimated between fixing date + settlement delay and the maturity date. However this maturity date must not be confuesd with the end date of the coupon, in the example I posted the different dates are coupon ====== start date = 22.08.2014 end date = 24.11.2014 fixing date = 20.11.2014 payment date = 24.11.2014 index ==== d1 = 24.11.2014 d2 = 25.05.2015 As you can see, indeed d1 = end date, but this doesn't really matter, the forward rate is estimated on [d1, d2]. Is it clearer now ? Thanks Peter On 27 August 2014 14:56, Pavan Mandalkar <[hidden email]> wrote: > Hello Peter, > > Thanks for you patience on this; we were able to reproduce the issue with > your simple code both in v1.1 and v1.4. > > Borrowing writing from my previous mail: > The way we interpret the 'in arrears' option to work is that the actual > fixing has to be forecasted 2 (or appropriately specified > prior-business-days) days before maturity. > Therefore the fixing period should not be zero; in the example supplied we > see that is always turns out to be zero - when the 'fixingdate' is advanced > to 'fixingValueDate' which will be same as 'endValueDate'. > > I have added the (image of) code changes we had to perform to get the code > working; kindly do review and let us know your thoughts. > > http://i.minus.com/jbjQThR9g9yi9o.png > > > > Thanks > Pavan M > > > On Wed, Aug 20, 2014 at 3:07 PM, Peter Caspers <[hidden email]> > wrote: >> >> Hi Pavan, >> >> here is a simple example using an in arrears ibor coupon >> >> https://gist.github.com/pcaspers/f8d0500b4852ae94c32f >> >> do you see the problem you describe there, too ? Or can you post some >> code that produces your problem ? >> >> best regards >> Peter >> >> On 19 August 2014 11:57, Pavan Mandalkar <[hidden email]> >> wrote: >> > Hello, >> > >> > Facing an issue with IborIndex::forecastFixing(...) function - >> > <root>\ql\indexes\iborindex.cpp. >> > What is the difference between 'fixingValueDate' and 'fixingDate' [QLib >> > v1.1 >> > variable names] >> > >> > We are using QLib 1.1 - but have compared the functionality in v1.4 as >> > well >> > - but no business logic has changed. >> > Only that v1.4 enhances the error catching (to prevent a 0/0) and it is >> > more >> > modularized. >> > >> > Business case: >> > Trying to price an Option-let (Caplet / Floorlet) which is Fixed in >> > *Arrears*. We pass, the fixing days as '2 business days prior' during >> > the >> > IborLeg formation. >> > [This can be simulated by any floating rate instrument which requires a >> > forecasted fixing] >> > During the evaluation of Option via the pricing engine, the fixing_date >> > is >> > returned as 2 days prior to maturity of the leg. >> > Since, the fixing_rate is in the future, it has to be forecasted. It >> > ends up >> > in the above function. >> > >> > We believe there is a bug in calculation of period between >> > fixing_value_date >> > and end_value_date. [QLib v1.4 variable names inside flower braces{}] >> > Basically, in the function, this turns out to be zero. The reason being, >> > the >> > passed in (parameter) fixing_dateis converted to fixing_value_date {d1} >> > - >> > via the function valueDate. >> > valueDate function, 'advances' the fixing_date by fixing_days (which is >> > 2) >> > to return the mautrity date of the option-let. >> > The end_value_date {d2} would turn out to be maturity date. >> > Therefore it is zero. >> > >> > This is solved, by choosing to calculate the term between unaltered >> > fixing_date and end_date. >> > The discount factors would be different (depending on the curve) and >> > forecast fixing would be generated. >> > >> > Have tried to search the forums with 'forecastFixing' but have not found >> > any >> > relevant material. >> > Would be glad if someone pointed out any information. >> > I will raise this as a bug - for now, but would be glad to stand >> > corrected - >> > and learn the right usage. >> > >> > >> > Thanks >> > Pavan M >> > >> > >> > ------------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > QuantLib-users mailing list >> > [hidden email] >> > https://lists.sourceforge.net/lists/listinfo/quantlib-users >> > > > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hello Peter, Thanks for the email. Wondering in the example you sent - which fails for us on v1.4 - does this produce a result for you? ["std::cout << "adjusted fixing = " << coupon->adjustedFixing() << std::endl;"] -
For us - it is the edge case; we are pricing a cap (containing only one caplet), setup with a IBORCoupon, where the end-date is equal to the maturity-date. In this case d1 becomes equal to d2 (with current QLib code) - thus raising the assertion and eventually the failure.
So would it be incorrect to have a Cap (caplet) where the coupon end-date is equal to maturity-date? Is there a different way we should set it up (pass parameters to QLib) such that the time difference is not zero?
Another query related to your last email: where is the date of 25/05/2015 mentioned. Sorry, I may be missing something; I do not see it on the example. Thanks Pavan M On Wed, Aug 27, 2014 at 5:22 PM, Peter Caspers <[hidden email]> wrote: Hi Pavan, ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hi Pavan,
are you saying that you do not get a result from coupon->adjustedFixing() in my example code when compiling against ql 1.4 ? What do you get instead, zero or an exception or something else ? d1 and d2 are not output of the example code, these are the dates from the ql code in question (taken from a debug session). kind regards Peter On 29 August 2014 18:45, Pavan Mandalkar <[hidden email]> wrote: > Hello Peter, > > Thanks for the email. > > Wondering in the example you sent - which fails for us on v1.4 - does this > produce a result for you? > ["std::cout << "adjusted fixing = " << coupon->adjustedFixing() << > std::endl;"] - > > For us - it is the edge case; we are pricing a cap (containing only one > caplet), setup with a IBORCoupon, where the end-date is equal to the > maturity-date. > In this case d1 becomes equal to d2 (with current QLib code) - thus raising > the assertion and eventually the failure. > > So would it be incorrect to have a Cap (caplet) where the coupon end-date is > equal to maturity-date? > Is there a different way we should set it up (pass parameters to QLib) such > that the time difference is not zero? > > Another query related to your last email: where is the date of 25/05/2015 > mentioned. Sorry, I may be missing something; I do not see it on the > example. > > > > Thanks > Pavan M > > > On Wed, Aug 27, 2014 at 5:22 PM, Peter Caspers <[hidden email]> > wrote: >> >> Hi Pavan, >> >> I think the current QuantLib code is correct, the forward rate needs >> to be estimated between fixing date + settlement delay and the >> maturity date. >> >> However this maturity date must not be confuesd with the end date of >> the coupon, in the example I posted the different dates are >> >> coupon >> ====== >> start date = 22.08.2014 >> end date = 24.11.2014 >> fixing date = 20.11.2014 >> payment date = 24.11.2014 >> >> index >> ==== >> d1 = 24.11.2014 >> d2 = 25.05.2015 >> >> As you can see, indeed d1 = end date, but this doesn't really matter, >> the forward rate is estimated on [d1, d2]. >> >> Is it clearer now ? >> >> Thanks >> Peter >> >> >> On 27 August 2014 14:56, Pavan Mandalkar <[hidden email]> >> wrote: >> > Hello Peter, >> > >> > Thanks for you patience on this; we were able to reproduce the issue >> > with >> > your simple code both in v1.1 and v1.4. >> > >> > Borrowing writing from my previous mail: >> > The way we interpret the 'in arrears' option to work is that the actual >> > fixing has to be forecasted 2 (or appropriately specified >> > prior-business-days) days before maturity. >> > Therefore the fixing period should not be zero; in the example supplied >> > we >> > see that is always turns out to be zero - when the 'fixingdate' is >> > advanced >> > to 'fixingValueDate' which will be same as 'endValueDate'. >> > >> > I have added the (image of) code changes we had to perform to get the >> > code >> > working; kindly do review and let us know your thoughts. >> > >> > http://i.minus.com/jbjQThR9g9yi9o.png >> > >> > >> > >> > Thanks >> > Pavan M >> > >> > >> > On Wed, Aug 20, 2014 at 3:07 PM, Peter Caspers <[hidden email]> >> > wrote: >> >> >> >> Hi Pavan, >> >> >> >> here is a simple example using an in arrears ibor coupon >> >> >> >> https://gist.github.com/pcaspers/f8d0500b4852ae94c32f >> >> >> >> do you see the problem you describe there, too ? Or can you post some >> >> code that produces your problem ? >> >> >> >> best regards >> >> Peter >> >> >> >> On 19 August 2014 11:57, Pavan Mandalkar <[hidden email]> >> >> wrote: >> >> > Hello, >> >> > >> >> > Facing an issue with IborIndex::forecastFixing(...) function - >> >> > <root>\ql\indexes\iborindex.cpp. >> >> > What is the difference between 'fixingValueDate' and 'fixingDate' >> >> > [QLib >> >> > v1.1 >> >> > variable names] >> >> > >> >> > We are using QLib 1.1 - but have compared the functionality in v1.4 >> >> > as >> >> > well >> >> > - but no business logic has changed. >> >> > Only that v1.4 enhances the error catching (to prevent a 0/0) and it >> >> > is >> >> > more >> >> > modularized. >> >> > >> >> > Business case: >> >> > Trying to price an Option-let (Caplet / Floorlet) which is Fixed in >> >> > *Arrears*. We pass, the fixing days as '2 business days prior' during >> >> > the >> >> > IborLeg formation. >> >> > [This can be simulated by any floating rate instrument which requires >> >> > a >> >> > forecasted fixing] >> >> > During the evaluation of Option via the pricing engine, the >> >> > fixing_date >> >> > is >> >> > returned as 2 days prior to maturity of the leg. >> >> > Since, the fixing_rate is in the future, it has to be forecasted. It >> >> > ends up >> >> > in the above function. >> >> > >> >> > We believe there is a bug in calculation of period between >> >> > fixing_value_date >> >> > and end_value_date. [QLib v1.4 variable names inside flower braces{}] >> >> > Basically, in the function, this turns out to be zero. The reason >> >> > being, >> >> > the >> >> > passed in (parameter) fixing_dateis converted to fixing_value_date >> >> > {d1} >> >> > - >> >> > via the function valueDate. >> >> > valueDate function, 'advances' the fixing_date by fixing_days (which >> >> > is >> >> > 2) >> >> > to return the mautrity date of the option-let. >> >> > The end_value_date {d2} would turn out to be maturity date. >> >> > Therefore it is zero. >> >> > >> >> > This is solved, by choosing to calculate the term between unaltered >> >> > fixing_date and end_date. >> >> > The discount factors would be different (depending on the curve) and >> >> > forecast fixing would be generated. >> >> > >> >> > Have tried to search the forums with 'forecastFixing' but have not >> >> > found >> >> > any >> >> > relevant material. >> >> > Would be glad if someone pointed out any information. >> >> > I will raise this as a bug - for now, but would be glad to stand >> >> > corrected - >> >> > and learn the right usage. >> >> > >> >> > >> >> > Thanks >> >> > Pavan M >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > >> >> > _______________________________________________ >> >> > QuantLib-users mailing list >> >> > [hidden email] >> >> > https://lists.sourceforge.net/lists/listinfo/quantlib-users >> >> > >> > >> > > > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Re: ForecastFixing issue - option paying InArrears
|
|
Hello Peter, The code in v1.4 works fine; from your example, we realized one of the initialized parameters was incorrect. Thanks for the mail; apologies for the late reply. We were migrating to QLib v1.4 and wanted to wait to test with the same before I answered. Thanks Pavan M On Fri, Aug 29, 2014 at 8:04 PM, Peter Caspers <[hidden email]> wrote: Hi Pavan, ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
«
Return to quantlib-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |