Day counters in Swaps

[Bill Q]

Hello Everyone

Working my way through the SimpleSwap example I became a little confused
with the floating side day counter.

On the fixed leg side of the swap the FixedRateCoupon has its own day
counter, which seems well and good. However on the floating leg side the
FloatingRateCoupon does not. It does however contain an Index which has a
day counter. But it doesn't use that. Instead it uses the day counter in the
term structure contained in the index.

inline DayCounter FloatingRateCoupon::dayCounter() const {
    return index_->termStructure()->dayCounter();
}

Now the term structure uses its day counter during the bootstrap process
when it adds to the times_ vector, so it will have an effect on the term
structure.

And so to my question. Does the day counter on the floating side of a swap
always have to match the day counter used in the forecasting term structure?

[Luigi Ballabio-2]

At 11:28 AM -0600 1/24/03, Bill Q wrote:
>Working my way through the SimpleSwap example I became a little confused
>with the floating side day counter.
>
>On the fixed leg side of the swap the FixedRateCoupon has its own day
>counter, which seems well and good. However on the floating leg side the
>FloatingRateCoupon does not. Instead it uses the day counter in the
>term structure contained in the index.

Bill,
        you're putting salt on an old wound of mine :) I raised the
same exception in the past, but with no luck.

The fact is, the floating rate coupon implemented in QuantLib is a
coupon at par on the term structure---which seems to be the orthodox
way to price a coupon.

(Warning: rant ahead)

Well, it does have the nice property that the value of the floating
leg is (apart from the value of the notional) exactly 1, which is
very convenient when one is writing papers. There are other arguments
in its favor, making use of mysterious and magic words like
Martingale :)

But the problem is that, even if the day counters were the same, what
we're forecasting is not the actual floating rate fixing. And I still
haven't seen any hard numbers proving to me that the error we're
making this way is smaller that the error we would be making by
discounting the forecasted value of the real coupon on a period which
is one or two days longer or shorter than its "natural" duration.

On top of this, there's the day counter problem you submitted---i.e.,
if a bond is issued which pays the fixing of the 6-months Euribor
act/360, but accruing it with e.g. the act/act convention (I've seen
it, I'm not making it up), the par coupon is just useless.

(end of rant. Sometimes I have to let it out, you know)

Now, the problem is not _that_ bad. We can keep the par coupon as we
know and <cough> love it---there are legitimate uses for it, after
all, and I'm not a RIAA executive :) We just derive from Coupon
another class which actually uses the Index it contains (for the sake
of this argument, let's call this class IndexedCoupon), or better
yet, we can make FloatingCoupon a purely virtual class and inherit
both ParCoupon and IndexedCoupon from it. This is just what I would
have done from the beginning, had I not been talked out of it (names
pulled to protect the guilty :)

My problem is, I already had to implement IndexedCoupon (I told you I
had seen cases where I needed) and at this time I'm not allowed to
move code from our proprietary repository to QuantLib.
<hint> However, I someone else writes and contributes it---which
could be a nice exercise for someone that wants to work with
QuantLib, too---the problem vanishes, and I can review it and make it
fit the rest of the architecture if there's any need to do it. </hint>

Bye for now,
        a much calmer Luigi