Posted by
Toyin Akin-3 on
Mar 29, 2002; 11:21pm
URL: http://quantlib.414.s1.nabble.com/Floating-Coupons-tp1948p1950.html
Hi Luigi,
(You may have recieved this already, I changed my clock settings earlier and
thus the timestamp
on my mail is incorrect...anyway I've tacked on a bit more at the bottom,
sunnary section.)
You wrote...
> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
> (discount(start)/discount(end))-1)
> ---------------------------------- * actact(end-start) * notional,
> act365(end-start)
I am confused as to why you divide by act365(end-start).
Lets say that I am in the middle of a period. The period has fixed and I was
to pay Libor fixing
act/act. I would look up a reuters page and pick the fixing based on actact
and not act365
(assuming that act365 is the market convention).
In your calculation, by dividing by act365, the Fra rate (or fixing if you
like) is based on act365. But the client wants a fixing based on actact. So
even if there were no date adjustments due to weekends and holidays and the
dates/period is exactly the same as the fixing period, the rate
you have computed is incorrect.
In fact on some reuters pages where you see both fixings being quoted on
act365 and actact, you can convert from one to the other by multiplying by
the ratio of the daycount fractions.
*** NEW BIT ***
In summary...
If the question is a client wants to pay LIBOR(act/act) over a
daycountfraction of act/act
then you divide by act/act. If the question is that the client wants to pay
LIBOR(act/365) over a daycountfraction of act/act (a pretty wierd request I
must say) then I see your point. However
I was under the impression that the definition of a particular fixing rate
(LIBOR rate if you like)
indicates the daycountfraction over which the rate is to be paid out.
In fact looking at your Indexes namespace, it looks like for each currency,
you have hard coded
the daycountfraction convention. You either need a new Euribor365 index, or
have the daycountfraction passed in as a parameter.
Regards,
Toy.
----- Original Message -----
From: "Luigi Ballabio" <
[hidden email]>
To: "Toyin Akin" <
[hidden email]>;
<
[hidden email]>
Sent: Friday, March 29, 2002 4:21 PM
Subject: Re: [Quantlib-users] Floating Coupons
>
> Hi Toyin,
> thanks for answering.
>
> At 06:08 PM 3/28/02 +0000, Toyin Akin wrote:
> >In my opinion I would use the former.
> >
> >(discount(start)/discount(end)-1.0) * nominal
> >
> >One argument for this is that you can reduce the value of the float side
> >of a swap to just the exchange of notionals. [(dcf(start) - dcf(end5y)) *
> >Notional]
> >
> >If you employ liborFixing * accrualPeriod * nominal, this will not
happen.
>
> I was aware of the simplification above, but I don't think that it's an
> issue here since the Swap class is simply collecting the amounts from the
> CashFlow instances in its legs and adding them up. The swap doesn't
inspect
> its cash flows to see whether they are fixed or floating, it just
delegates
> to each of them its own calculation. Thus, there is no way to perform the
> symbolic calculation above.
>
> >In addition the former formula will contain the least error as you'll
find
> >that if the first Fra period is slightly longer than normal, the period
> >following it will be shorter.
> >So the errors roughly cancels out.
>
> Ok, I see this point.
>
> (even though I could be picky and reply that if the _last_ period was
> longer, there wouldn't be a shorter period to cancel out the error. Or if
> we were already in the middle of the longer period, its fixing was
> determined and would no longer cancel out the error of the following
> shorter one.
> As a matter of fact, I could be even nastier and point out that if forward
> rates were allowed to be negative, there would be no guarantee that the
> shorter period would cancel out the longer one; the two errors could add
up
> instead. But I won't be picky)
>
> >You are right that the liborFixing is what is actually paid, but for
> >calculation purposes
> >if we are in the middle of a period where a rate has been fixed, then use
> >the actual fixed value
> >(latter formula), for future cash flows use the former.
>
> Yes, this is what is done right now.
>
> However, I'm not objecting to par coupons as such, but rather to attempts
> to extend them beyond their possibilities. For instance, adding a spread
is
> still safe, but it forces one to add a parameter since the formula
> (discount(start)/discount(end)-1)*notional
> now must become
> [(discount(start)/discount(end)-1) + spread*accrualPeriod] *
notional
> and a day counter (or an index, which contains a day counter) must be
> passed to calculate the accrual period. But this can already be
misleading:
> if one writes
> FloatingCoupon(start,end,termStructure,0.0,actualactual)
> he might think he is instantiating a coupon which pays the Libor fixing
> over an accrual period calculated act/act, when in fact the act/act day
> count is not used at all since he passed a 0.0 spread.
>
> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
> (discount(start)/discount(end))-1)
> ---------------------------------- * actact(end-start) * notional,
> act365(end-start)
> which does no longer simplify? Or should one go ahead and use
> liborFixing * actact(end-start) * notional
> and save himself the trouble?
>
> I guess the question boils down to, what is the market practice these
days?
>
> Bye,
> Luigi
>