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
>> >> >
>> >
>> >
>
>
| Free forum by Nabble | Edit this page |