QuantLib › quantlib-users

DayCounter question regarding ActualActual::AFB

Classic

List

Threaded

3 messages Options

Dagur Gunnarsson-2

DayCounter question regarding ActualActual::AFB

hello,

should the ActualActual::AFB DayCounter method not use 366 in the denominator, when calculation yearFraction, instead of 365 for a period containing 29th of february 2012? At least according to http://en.wikipedia.org/wiki/Day_count_convention#Actual.2FActual_AFB

the following :

DayCounter dayCounter = ActualActual(ActualActual::AFB);

cout<<setprecision(10)

<<"Yearfraction = "

<<dayCounter.yearFraction(Date(8, Mar, 2012), Date(17, May, 2012), Date(17, May, 2011), Date(17, May, 2012))<<endl

<<"Daycount = "<<dayCounter.dayCount(Date(8, Mar, 2012), Date(17, May, 2012))<<endl;

gives

Yearfraction = 0.1917808219 --> 70/365 and not 70/366

Daycount = 70

am i wrong here?

regards

Dagur G

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Luigi Ballabio

Re: DayCounter question regarding ActualActual::AFB

Hello Dagur,
I'm not sure about this. The ISDA docs at
<http://www.isda.org/publications/pdf/Day-Count-Fracation1999.pdf> say
the same thing as the Wikipedia page you linked (or possibly the other
way around), that is, "the denominator is either 365 (if the
calculation period does not contain 29th February) or 366 (if the
calculation period includes 29th February)".

I'm not sure how to interpret this, though. Evidently, the library
takes the above to mean that since the calculation period (March 8th
2012 to May 17th 2012) doesn't include February 29th, then the
denominator should be 365. In fact, the current implementation
doesn't use at all the third and fourth date passed to the method. On
the other hand, you take it to mean that the passed reference period
should be used for the check. I tend to lean towards the first
interpretation, but I see your point, too.

Unfortunately, the ISDA docs don't provide an example case to
disambiguate. Is the period you're trying to measure the short coupon
of a bond? If so, do you have access to its cash-flow analysis?
(Bloomberg, Reuters...)

Luigi

On Wed, Mar 7, 2012 at 4:19 PM, Dagur Gunnarsson <[hidden email]> wrote:

> should the ActualActual::AFB DayCounter method not use 366 in the
> denominator, when calculation yearFraction, instead of 365 for a period
> containing 29th of february 2012? At least according
> to http://en.wikipedia.org/wiki/Day_count_convention#Actual.2FActual_AFB
>
> the following :
>
> DayCounter dayCounter = ActualActual(ActualActual::AFB);
> cout<<setprecision(10)
> <<"Yearfraction = "
> <<dayCounter.yearFraction(Date(8, Mar, 2012), Date(17, May, 2012),
> Date(17, May, 2011), Date(17, May, 2012))<<endl
> <<"Daycount = "<<dayCounter.dayCount(Date(8, Mar, 2012), Date(17, May,
> 2012))<<endl;
>
> gives
>
> Yearfraction = 0.1917808219 --> 70/365 and not 70/366
> Daycount = 70
>
> am i wrong here?

Dagur Gunnarsson-2

Re: DayCounter question regarding ActualActual::AFB

Hello,

This is quite tricky - in the document you linked, it states that ISMA uses the number of days in the "coupon period", as the denominator for the yearfraction calculation, but for AFB the denominator should be 365 or 366 depending on whether 29th of february is included in the "calculation period". In the node on the same page, as the definitions of ISMA, ISDA and AFB methods, it says that the term "calculation period" bears the same meaning as in the 1991 ISDA Definitions. I do not have access to the 1991 ISDA definitions, but there seems to be a clear distinctions between the terms "coupon period" and "calculation period", so I also lean towards the current implementation.

regards

Dagur G

On Wed, Mar 7, 2012 at 4:36 PM, Luigi Ballabio <[hidden email]> wrote:

Hello Dagur,
I'm not sure about this. The ISDA docs at
<http://www.isda.org/publications/pdf/Day-Count-Fracation1999.pdf> say
the same thing as the Wikipedia page you linked (or possibly the other
way around), that is, "the denominator is either 365 (if the
calculation period does not contain 29th February) or 366 (if the
calculation period includes 29th February)".

I'm not sure how to interpret this, though. Evidently, the library
takes the above to mean that since the calculation period (March 8th
2012 to May 17th 2012) doesn't include February 29th, then the
denominator should be 365. In fact, the current implementation
doesn't use at all the third and fourth date passed to the method. On
the other hand, you take it to mean that the passed reference period
should be used for the check. I tend to lean towards the first
interpretation, but I see your point, too.

Unfortunately, the ISDA docs don't provide an example case to
disambiguate. Is the period you're trying to measure the short coupon
of a bond? If so, do you have access to its cash-flow analysis?
(Bloomberg, Reuters...)

Luigi

On Wed, Mar 7, 2012 at 4:19 PM, Dagur Gunnarsson <[hidden email]> wrote:
> should the ActualActual::AFB DayCounter method not use 366 in the
> denominator, when calculation yearFraction, instead of 365 for a period
> containing 29th of february 2012? At least according
> to http://en.wikipedia.org/wiki/Day_count_convention#Actual.2FActual_AFB
>
> the following :
>
> DayCounter dayCounter = ActualActual(ActualActual::AFB);
> cout<<setprecision(10)
> <<"Yearfraction = "
> <<dayCounter.yearFraction(Date(8, Mar, 2012), Date(17, May, 2012),
> Date(17, May, 2011), Date(17, May, 2012))<<endl
> <<"Daycount = "<<dayCounter.dayCount(Date(8, Mar, 2012), Date(17, May,
> 2012))<<endl;
>
> gives
>
> Yearfraction = 0.1917808219 --> 70/365 and not 70/366
> Daycount = 70
>
> am i wrong here?