http://quantlib.414.s1.nabble.com/Question-on-floating-cashflows-tp5229p5231.html
the Schedule class doesn't handle IMM dates yet. This said I suggest
> Thanks for your response.
>
>
> On the question of the schedule, how are compounding coupons handled?
> It seems that given cashflows driven by the Schedule this would involve
> a new type of cash flow which has multiple resets inside? I was unable
> to find an example in the QL code of something like a compounding coupon
> with two or more resets per cash flow. Am I making any sense?
>
>
> Here is the information on the CDS. Perhaps the convention is to use
> unadjusted for the dates .But it was not clear that dates other than
> effective and termination are unadjusted.
>
>
http://www.fincad.com/support/developerFunc/mathref/cds.htm>
> Contra_d is a table of default swap date(s). It can have 2 to 7entries.
> The first four entries hold in sequence the terminating date, effective
> date, odd first coupon date and next-to-last coupon date for premium
> payments. The last three entries hold switch values in sequence the
> effective date adjustment, terminating date adjustment and date
> generation method for premium payments. Only the terminating date and
> effective date are required. The third entry and fourth entry will
> default to 0 and the last three entries will default to 1 (adjust
> effective date, adjust terminating date, backward date generation). Note
> that for most credit default swaps in the market, the effective date and
> maturity date are not adjusted and the premium cash flow dates are IMM
> dates. For this case, simply set both the effective date and maturity
> date adjustment methods (the 5^th and 6^th entries in the table) to 2
> (no adjustment) and the date generation method (the 7^th entry in the
> table) to 3 (IMM date generation method).
>
> Thanks.
> Jay
>
>
> Ferdinando Ametrano wrote:
> > Hi Jay
> >
> >
> >> #1 - Why do we adjust the dates twice, they are adjusted already in the Schedule
> >> constructor.
> >>
> > the dates calculated in the Schedule are the accrual dates. They are
> > adjusted with whatever convention is appropriate for the given deal.
> > Later on payment dates are needed and they are calculated from the
> > accrual date with the proper adjustment
> >
> >
> >> #2 - Market convention on a CDS (which isn't currently in QL) is apparently to have an
> >> unadjusted start date, there is currently not an option to do this in the current Schedule
> >> object.
> >>
> > What you write doesn't seem correct to me, but maybe I'm missing the
> > point. Please provide a concrete realistic example of a schedule which
> > cannot be calculated by the Schedule class and I'l look into it
> >
> >
> >> there is a comment
> >>
> >> // the following is not always correct
> >> Calendar calendar = schedule.calendar();
> >> #3 - What does the comment mean, and should a different calendar object be passed in to
> >> the FixedLeg method? When is using the calendar from Schedule incorrect?
> >>
> >
> > the payment calendar might be different from the calendar used to
> > calculate the accrual dates in the Schedule class. In this case
> > FixedLeg would not be flexible enough
> >
> >
> >> #4 - I am building USD Libor swaps and am using the joint UK, US calendar as the calendar
> >> in the Schedule. This appears to generate the proper sequence of reset/pay dates.
> >>
> > glad to know it.
> >
> >
> >> The Swap example in testsuite/swapvaluation.cpp only deals with a Euro swap which is a
> >> simpler case due to only needing the Target calendar.
> >>
> > fell free to provide some significant schedule to be reproduced in
> > the test suite and I will add it
> >
> > ciao -- Nando
> >
> >
>
Defy all challenges. Microsoft(R) Visual Studio 2005.