Re: ForecastFixing issue - option paying InArrears

Posted by Pavan Mandalkar on
URL: http://quantlib.414.s1.nabble.com/ForecastFixing-issue-option-paying-InArrears-tp15766p15813.html

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