Forwards

[Luigi Ballabio-4]

At 01:35 PM 4/24/02 +0200, Andre Louw wrote:
(while discussing TermStructure implementations)
>Why exactly would you calculate an instantaneous forward instead of
>calculating out of spot? When would you use it?

Well, the curve of the instantaneous forwards at time t and the curve of
the forwards between 0 and t can be deduced from each other, so there's no
phylosophical reason to favor one or the other. We wrote termstructure.hpp
almost a couple of years ago, and my memory is a bit foggy on this
particular choice. I guess that we didn't put both in the interface because
we wanted to keep it lean, and that we were already thinking of
implementing a piecewise flat forward curve so that we chose instantaneous
forwards because the curve would have modeled the latter. It was a kind of
a ius primae noctis on our part :)

This said, I see that implementing a CompoundForward curve would lead you
more naturally to model forwards from now to t. We could save both
approaches by adding the latter forwards to the TermStructure interface and
adding default implementations which calculate one given the other, as it
is done for instance in DiscountStructure where you model the discounts and
get forwards and zero yields for free. The hardest part will be to find
suitable names to distinguish the two methods---I don't think that
instantaneousForward(t) would be that appealing :)

Thoughts?

Bye,
         Luigi

[Ferdinando M. Ametrano-2]

At 03:01 PM 4/24/2002 +0100, Luigi Ballabio wrote:
>At 01:35 PM 4/24/02 +0200, Andre Louw wrote:
>(while discussing TermStructure implementations)
>>Why exactly would you calculate an instantaneous forward instead of
>>calculating out of spot? When would you use it?
>
>Well, the curve of the instantaneous forwards at time t and the curve of
>the forwards between 0 and t can be deduced from each other, so there's no
>phylosophical reason to favor one or the other.
The QuantLib term structure interface allows for modelling of discount,
zero rate or forward rate based curves. There is no preference towards
forward except that the only working bootstrapping procedure provided is
for forward rates. The discount based curve you committed to the CVS is a
welcome addition.
A TermStructure based on par swap is missing.

Luigi:
>[...] implementing a CompoundForward curve would lead you more naturally
>to model forwards from now to t. We could save both approaches by adding
>the latter forwards to the TermStructure interface and adding default
>implementations which calculate one given the other, as it is done for
>instance in DiscountStructure where you model the discounts and get
>forwards and zero yields for free.
A method for the calculation of the forward rate from time t1 to time t2
was an omission we should fix (please note t1->t2, not just now->t),
especially as long our Monte Carlo and Finite Difference framework grow up
to time-dependent interest rate.

As far as CompoundForward is concerned I haven't take a look at the code
yet, but in my mind compounding rule and compounding frequency should be
handled in a transparent way in the general TermStructure interface:
another omission of our original design when we assumed that everybody
would have been happy with annual continuos compounding.

ciao -- Nando

[Luigi Ballabio-4]

At 03:13 PM 4/24/02 +0200, Ferdinando Ametrano wrote:

>At 03:01 PM 4/24/2002 +0100, Luigi Ballabio wrote:
>>At 01:35 PM 4/24/02 +0200, Andre Louw wrote:
>>>Why exactly would you calculate an instantaneous forward instead of
>>>calculating out of spot? When would you use it?
>>
>>Well, the curve of the instantaneous forwards at time t and the curve of
>>the forwards between 0 and t can be deduced from each other, so there's
>>no phylosophical reason to favor one or the other.
>The QuantLib term structure interface allows for modelling of discount,
>zero rate or forward rate based curves. There is no preference towards
>forward.

No, the question was: in case of forward rates, why instantaneous ones and
not finite-time ones? discounts and zeroes were taken for granted already.
The point being: once you model discounts, zero rates or instantaneous
forward rates, of course you can write a method returning forwards from t1
to t2.
But what if I want to model the forwards from t1 to t2 and derive
discounts, zeroes and instantaneous forwards from them?

Just to clarify the question.

Bye,
         Luigi

[Ferdinando M. Ametrano-2]

At 03:44 PM 4/24/2002 +0100, Luigi Ballabio wrote:
>>The QuantLib term structure interface allows for modelling of discount,
>>zero rate or forward rate based curves. There is no preference towards forward.
>No, the question was: in case of forward rates, why instantaneous ones and
>not finite-time ones?
>[...] what if I want to model the forwards from t1 to t2 and derive
>discounts, zeroes and instantaneous forwards from them?
There is not a real difference between instantaneous and finite-time forwards.
In the following with NxM, M>N I means a forward rate agreement (FRA) to
enter into a M-N months deposit N months from today.
If you're thinking about a yield curve representation in terms of [0x3,
3x6, 6x9, ...] FRA this is equivalent to have a piecewise constant
instantaneous forward curve with nodes [0,3,6,9,...]
If you're thinking about a yield curve built from something like [0x3, 1x4,
3x9, ...] this is equivalent to a [0x1, 1x3, 3x4, 4x9, ...] FRA strip, i.e.
a piecewise constant instantaneous forward curve with nodes [0, 1, 3, 4, 9,
...]
When you settle on the instantaneous forward parametrization there are no
problem to calculate whatever FRA. This is not true if you parametrize your
curve as a FRA strip, e.g. [0x1, 1x3, 3x4, 4x9, ...], since in this case
there are many plausible combinations of intermediate FRAs, e.g. the (1x2,
2x3) pair

Maybe I'm missing something here, but when it comes to internal yield curve
representation I know of discount, zero, instantaneous forward, and par
rates only.
Always willing to learn something more ....

>The point being: once you model discounts, zero rates or instantaneous
>forward rates, of course you can write a method returning forwards from t1
>to t2.
I committed such a method in the CVS, along with some code refactoring in
order to make the subject clearer.

What was poorly documented before is that in the TermStructure interface
all rates are assumed to be annual (time measured in years) continuos
compounding.
This requirement is not the best choice, but to change it would be a lot of
work since it's a pervasive assumption.
This means that TermStructure::forward(Date d1, Date d2) will not return a
FRA quote, since FRA are usually quoted with simple compounding.

Another point that I want to make clear is that I'm talking about internal
yield curve parametrization. There is no problem in using FRA to calibrate
your favorite yield curve parametrization, whatever your favorite is

ciao -- Nando

[Luigi Ballabio-4]

At 7:48 PM +0200 4/24/02, Ferdinando Ametrano wrote:
>At 03:44 PM 4/24/2002 +0100, Luigi Ballabio wrote:
>>>The QuantLib term structure interface allows for modelling of
>>>discount, zero rate or forward rate based curves. There is no
>>>preference towards forward.
>>No, the question was: in case of forward rates, why instantaneous
>>ones and not finite-time ones?
>>[...] what if I want to model the forwards from t1 to t2 and derive
>>discounts, zeroes and instantaneous forwards from them?
>There is not a real difference between instantaneous and finite-time forwards.

Of course there is not.
There is no real difference between forwards and discounts, either:
given one curve you can calculate the other and viceversa :)

>When you settle on the instantaneous forward parametrization there
>are no problem to calculate whatever FRA. This is not true if you
>parametrize your curve as a FRA strip, e.g. [0x1, 1x3, 3x4, 4x9,
>...], since in this case there are many plausible combinations of
>intermediate FRAs, e.g. the (1x2, 2x3) pair

Not true. You don't specify your curve as a FRA strip only: you give
a FRA strip *and* a functional form. A simple example which might not
make sense but gives the idea is: you store the deposit strip
[0x1,0x3,0x6,0x9,0x12] and assume that the 0xT rate is interpolated
linearly in T. Given this functional form, you can calculate whatever
FRA. And in this case, it would be discounts, zero yields, and
instantaneous forwards which would depend on the 0xT rates.
Also in the case of our curve, you give a number of instantaneous
forward at the nodes *and* a functional form (piecewise flat). The
former without the latter would not be sufficient.


>Maybe I'm missing something here, but when it comes to internal
>yield curve representation I know of discount, zero, instantaneous
>forward, and par rates only.

On this point I can agree. But there are more things in heaven and
earth, Horatio, than are dreamt of in your philosophy...


>What was poorly documented before is that in the TermStructure
>interface all rates are assumed to be annual (time measured in
>years) continuos compounding.
>This requirement is not the best choice, but to change it would be a
>lot of work since it's a pervasive assumption.
>This means that TermStructure::forward(Date d1, Date d2) will not
>return a FRA quote, since FRA are usually quoted with simple
>compounding.

That depends on what we decide (and on the name of the method. I
wouldn't overload forward() to give different kind of forward rates)

Bye,
        Luigi

--

[Ferdinando M. Ametrano-2]

At 10:22 PM 4/24/2002 +0200, Luigi wrote:
>>What was poorly documented before is that in the TermStructure interface
>>all rates are assumed to be annual (time measured in years) continuos
>>compounding.
>>This requirement is not the best choice, but to change it would be a lot
>>of work since it's a pervasive assumption.
>>This means that TermStructure::forward(Date d1, Date d2) will not return
>>a FRA quote, since FRA are usually quoted with simple compounding.
>That depends on what we decide (and on the name of the method. I wouldn't
>overload forward() to give different kind of forward rates)
I would prefer discrete forward rates to be equivalent to zero rates in the
sense that forwards are nothing else that zero rates as seen from a future
time, and zeros are forwards estimated 0.0 years from now.
Let's take a forward starting option (aka deferred strike) as example. To
value it one uses the usual Black-Scholes formula provided that the 'zero'
rate is replaced by the 'forward' rate. Now, if I'm supposed to feed our
Black-Scholes formula with a zero rate calculated by our TermStructure I
would like to be able to use a discrete forward rate as provided by our
TermStructure also in the case of forward options.

What about the following interface:
         //! discount factor at a given date
         DiscountFactor discount(const Date&, bool extrapolate = false) const;
         //! zero yield rate at a given date
         Rate zeroYield(const Date&, bool extrapolate = false) const;
         //! forward (zero) rate between two dates
         Rate forward(const Date&, const Date&, bool extrapolate = false)
const;
         //! instantaneous forward (zero) rate at a given date
         Rate instantaneousForward(const Date&, bool extrapolate = false)
const;

where of course zeroYield(myDate)==forward(settlementDate(), myDate) ?

ciao -- Nando

[Luigi Ballabio-4]

At 11:42 AM +0200 4/25/02, Ferdinando Ametrano wrote:

>What about the following interface:
>         //! discount factor at a given date
>         DiscountFactor discount(const Date&, bool extrapolate = false) const;
>         //! zero yield rate at a given date
>         Rate zeroYield(const Date&, bool extrapolate = false) const;
>         //! forward (zero) rate between two dates
>         Rate forward(const Date&, const Date&, bool extrapolate =
>false) const;
>         //! instantaneous forward (zero) rate at a given date
>         Rate instantaneousForward(const Date&, bool extrapolate =
>false) const;

I completely agree on the interface. But since I can't write a mail
in which I simply agree with you, :) I'd like a clarification of:

>where of course zeroYield(myDate)==forward(settlementDate(), myDate) ?

If you're talking of a mathematical relationship, the "of course" holds.
But if you're meaning that the above would be the implementation of
zeroYield, it is a possibility, but there's also the possibility to
have

forward(t1,t2) = (t2*zeroYield(t2)-t1*zeroYield(t1))/(t2-t1)

which would be more natural and effective if one modeled zero yields
internally, and therefore had the latter available at no cost.

I haven't given this any detailed thought, but were I to follow my
gut instinct, I would declare all of the above methods purely virtual
in TermStructure and implement relations such as the ones above in
derived classes such as DiscountStructure, ZeroYieldStructure, and
ForwardStructure.

Bye,
        Luigi

--

[Ferdinando M. Ametrano-2]

Hi all

At 02:05 PM 4/25/2002 +0200, Luigi Ballabio wrote:
>I'd like a clarification of:
>>where of course zeroYield(myDate)==forward(settlementDate(), myDate) ?
>If you're talking of a mathematical relationship, the "of course" holds.
>But if you're meaning that the above would be the implementation of
>zeroYield [..]
I meant the former.

>I haven't given this any detailed thought, but were I to follow my gut
>instinct, I would declare all of the above methods purely virtual
you know you can follow your gut instict ;-)

>I completely agree on the interface. But since I can't write a mail in
>which I simply agree with you, :) [...]
when we were working together this list had no chance to experience our
design discussion ... ;-)

ciao -- Nando

[Luigi Ballabio-4]

At 9:49 PM +0200 4/25/02, Ferdinando Ametrano wrote:
>>I completely agree on the interface. But since I can't write a mail
>>in which I simply agree with you, :) [...]
>when we were working together this list had no chance to experience
>our design discussion ... ;-)

They don't know how lucky they are.
The sight of you panting in exhaustion is not a pretty one. :)

Bye,
        Luigi


--