Question on floating cashflows

[Jay Walters]

I am looking at the QL 0.8.1 source code, so perhaps this has changed in SVN.

In the class Schedule, the constructor adjusts each of the dates given the calendar and business day convention specified as arguments.  Later on in the lifecycle of this object I will use it to create a FloatingLeg using the code in cashflowvectors.cpp.  In the method

   template <typename IndexType,
              typename FloatingCouponType,
              typename CappedFlooredCouponType>
    Leg FloatingLeg(const std::vector<Real>& nominals,
                    const Schedule& schedule,
                    const boost::shared_ptr<IndexType>& index,
                    const DayCounter& paymentDayCounter,
                    BusinessDayConvention paymentAdj,
                    Natural fixingDays,
                    const std::vector<Real>& gearings,
                    const std::vector<Spread>& spreads,
                    const std::vector<Rate>& caps,
                    const std::vector<Rate>& floors,
                    bool isInArrears) {

The code once again adjusts the dates using the calendar from the schedule (which shouldn't do anything), and there is a comment

        // the following is not always correct
        Calendar calendar = schedule.calendar();

A few questions.

#1 - Why do we adjust the dates twice, they are adjusted already in the Schedule constructor.

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

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

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

Jay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Ferdinando M. Ametrano-3]

Jay,

the Schedule class doesn't handle IMM dates yet. This said I suggest
you come up with a concrete sequence of date which you are not able to
generate using the Schedule class and I'll look into it.

I'm CCing the quantlib-users mailing list attaching your message below
as I think this might be of general interest

ciao -- Nando

On Nov 22, 2007 5:06 PM, Jay Walters <[hidden email]> wrote:

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users