QuantLib › quantlib-users

Do we really need to pass in parameter calendar in AmortizingFixedRateBond?

Classic

List

Threaded

3 messages Options

cheng li

Do we really need to pass in parameter calendar in AmortizingFixedRateBond?

Hi Team,

Currently AmortizingFixedRateBond’s second constructer function signature:

Line 155: AmortizingFixedRateBond::AmortizingFixedRateBond(

Natural settlementDays,

const Calendar& calendar,

Real initialFaceAmount,

const Date& startDate,

const Period& bondTenor,

const Frequency& sinkingFrequency,

const Rate coupon,

const DayCounter& accrualDayCounter,

BusinessDayConvention paymentConvention,

const Date& issueDate)

The second parameter calendar is used in sub function:

Line 173: sinkingSchedule(startDate, bondTenor, sinkingFrequency, calendar)

However as I see, in this function, the calendar is only used as：

Line 104: Schedule retVal(startDate, maturityDate, freqPeriod,

paymentCalendar, Unadjusted, Unadjusted,

DateGeneration::Backward, false);

As the convention is all passed as Unadjused, it seems paymentCalendar will have no any effect on generated retVal..

Am I missing something here?

Regards,

Cheng

Regards,

Cheng

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Luigi Ballabio

Re: Do we really need to pass in parameter calendar in AmortizingFixedRateBond?

Hi Cheng,
I'm not sure about it (it might as well be that we should also
pass an adjustment convention to the sinkingSchedule function) but the
calendar is used later for payment adjustment. The coupons are
generated in sinkingSchedule() with Unadjusted convention, so the
calendar is not used there, but it's stored into the returned schedule
anyway. When FixedRateLeg is called, it will use the calendar stored
in the schedule to adjust the payment date of the coupons with the
convention passed in the withPaymentAdjustment() method.

Luigi

On Tue, Sep 9, 2014 at 5:20 AM, cheng li <[hidden email]> wrote:

> Hi Team,
>
>
>
> Currently AmortizingFixedRateBond’s second constructer function signature:
>
>
>
> Line 155: AmortizingFixedRateBond::AmortizingFixedRateBond(
>
> Natural settlementDays,
>
> const Calendar& calendar,
>
> Real initialFaceAmount,
>
> const Date& startDate,
>
> const Period& bondTenor,
>
> const Frequency& sinkingFrequency,
>
> const Rate coupon,
>
> const DayCounter& accrualDayCounter,
>
> BusinessDayConvention
> paymentConvention,
>
> const Date& issueDate)
>
>
>
> The second parameter calendar is used in sub function:
>
> Line 173: sinkingSchedule(startDate, bondTenor, sinkingFrequency, calendar)
>
>
>
> However as I see, in this function, the calendar is only used as：
>
>
>
> Line 104: Schedule retVal(startDate, maturityDate, freqPeriod,
>
> paymentCalendar, Unadjusted, Unadjusted,
>
> DateGeneration::Backward, false);
>
>
>
> As the convention is all passed as Unadjused, it seems paymentCalendar will
> have no any effect on generated retVal..
>
>
>
> Am I missing something here?
>
>
>
> Regards,
>
> Cheng
>
>
>
>
>
> Regards,
>
> Cheng
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

cheng li

答复: Do we really need to pass in parameter calendar in AmortizingFixedRateBond?

Hi Lugi,

Thanks for that information. Yes I may miss that part. I'll look into it.

Regards,
Cheng

-----邮件原件-----
发件人: Luigi Ballabio [mailto:[hidden email]]
发送时间: 2014年9月19日 23:07
收件人: cheng li
抄送: QuantLib users
主题: Re: [Quantlib-users] Do we really need to pass in parameter calendar in AmortizingFixedRateBond?

Hi Cheng,
I'm not sure about it (it might as well be that we should also pass an adjustment convention to the sinkingSchedule function) but the calendar is used later for payment adjustment. The coupons are generated in sinkingSchedule() with Unadjusted convention, so the calendar is not used there, but it's stored into the returned schedule anyway. When FixedRateLeg is called, it will use the calendar stored in the schedule to adjust the payment date of the coupons with the convention passed in the withPaymentAdjustment() method.

Luigi

On Tue, Sep 9, 2014 at 5:20 AM, cheng li <[hidden email]> wrote:

> Hi Team,
>
>
>
> Currently AmortizingFixedRateBond’s second constructer function signature:
>
>
>
> Line 155: AmortizingFixedRateBond::AmortizingFixedRateBond(
>
> Natural settlementDays,
>
> const Calendar& calendar,
>
> Real initialFaceAmount,
>
> const Date& startDate,
>
> const Period& bondTenor,
>
> const Frequency&
> sinkingFrequency,
>
> const Rate coupon,
>
> const DayCounter&
> accrualDayCounter,
>
> BusinessDayConvention
> paymentConvention,
>
> const Date& issueDate)
>
>
>
> The second parameter calendar is used in sub function:
>
> Line 173: sinkingSchedule(startDate, bondTenor, sinkingFrequency,
> calendar)
>
>
>
> However as I see, in this function, the calendar is only used as：
>
>
>
> Line 104: Schedule retVal(startDate, maturityDate, freqPeriod,
>
> paymentCalendar, Unadjusted, Unadjusted,
>
> DateGeneration::Backward, false);
>
>
>
> As the convention is all passed as Unadjused, it seems paymentCalendar
> will have no any effect on generated retVal..
>
>
>
> Am I missing something here?
>
>
>
> Regards,
>
> Cheng
>
>
>
>
>
> Regards,
>
> Cheng
>
>
> ----------------------------------------------------------------------
> --------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.
> clktrk _______________________________________________
> QuantLib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>