DiscountCurve

[Ferdinando M. Ametrano-2]

Hi Andre

I did a few changes on TermStructures. I also did a few changes to
DiscountCurve:
1) 2 new methods:
            const std::vector<Date>& dates() const;
            const std::vector<Time>& times() const;
2) required sorted dates and decreasing discount factors in the constructor
3) removed forwardImpl and zeroYieldImpl. Now DiscountCurve uses these
methods as inherited by DiscountStructure

Point 3 is the most important. Taking a look at your implementation of
forwardImpl and zeroYieldImpl I spotted some inconsistencies with the
TermStructures interface, mainly the fact that forward(Date, bool) must
return an annual continuous compounded rate.
In TermStructure zero and forward rates are assumed to be continuous
compounded rates: this is probably an error we did in the original design,
but unless we fix it everywhere this is the way to go.

Please let me know if after my patch DiscountCurve still works the way you
wanted. I can always roll back my patch if needed.

I would also like to introduce another change: I would require the user to
provide a discount grid starting with the first discount equal to 1.00, so
that we can assume that the first date is the settlement date. I think this
would be safer. Here's what I have in mind:
         DiscountCurve::DiscountCurve(const Date & todaysDate,
             const Calendar & calendar, const DayCounter & dayCounter,
             Currency currency, const std::vector < Date > &dates,
             const std::vector < DiscountFactor > &discounts)
         : todaysDate_(todaysDate), settlementDate_(dates_[0]),
           calendar_(calendar), dayCounter_(dayCounter),
           currency_(currency), dates_(dates), discounts_(discounts) {

              QL_REQUIRE(dates.size()>1, "DiscountCurveDiscountCurve :"
                 " too few dates");
              QL_REQUIRE(discounts_[0]==1.0, "DiscountCurveDiscountCurve :"
                 " invalid first discount, not equal to one");
              QL_REQUIRE(todaysDate_<=settlementDate_,
                 "DiscountCurveDiscountCurve :"
                 " today's date greater than settlement date");

              times_.resize(dates.size());
              times_[0]=0.0;

              for(Size i = 1; i < dates.size(); i++) {
                  QL_REQUIRE(dates_[i]>dates_[i-1],
                     "DiscountCurveDiscountCurve : invalid date");
                  QL_REQUIRE(discounts_[i]<=discounts_[i-1],
                     "DiscountCurveDiscountCurve : invalid discount");
                  times_[i] = dayCounter_.yearFraction(settlementDate_,
                     dates_[i]);
              }

             interpolation_ = Handle < DfInterpolation >
                 (new DfInterpolation(times_.begin(), times_.end(),
                 discounts.begin(), true));
       }

I haven't applied this patch because it will change the constructor
signature, so I will wait for your approval.

thank you for your contribution

ciao -- Nando

PS please note this message is for the quantlib-dev list, not quantlib-users

PS2 I would also remove settlementDays() from the TermStructure interface.
It is not used anywhere in the library and it is misleading (e.g. it has no
relation with the settlement days of the instruments used to bootstrap the
curve).
Anyone against this change?

[Luigi Ballabio-4]

Hi all,

At 6:56 PM +0200 4/24/02, Ferdinando Ametrano wrote:
>In TermStructure zero and forward rates are assumed to be continuous
>compounded rates: this is probably an error we did in the original
>design, but unless we fix it everywhere this is the way to go.

I agree that the short-time goal is consistency with the present design.
However, "everywhere" is just PiecewiseFlatForward and the formulas
in DiscountCurve and such. I think it's still open for
discussion---it's release 0.3.0, not 3.0. This was the point of the
mail I sent this morning: I wanted the people on the list to discuss
the thing.
Also, I think that the discussion is only on forward rates: as for
zero yield rates, I think that zeroYield(exerciseDate) must return
what it does right now for Black-Scholes to work, mustn't it? Or do
you want to introduce another method called average() or something?


>I would also like to introduce another change: I would require the
>user to provide a discount grid starting with the first discount
>equal to 1.00, so that we can assume that the first date is the
>settlement date. I think this would be safer.

I had the same thought when I saw the class, but then I realized that
log-linear interpolation already guarantees that the discount at time
0.0 is always 1.0.


>PS2 I would also remove settlementDays() from the TermStructure
>interface. It is not used anywhere in the library and it is
>misleading (e.g. it has no relation with the settlement days of the
>instruments used to bootstrap the curve).
>Anyone against this change?

Not against this change as such. However, either one passes today's
date and a number of settlement days or today's date and the
settlement date. No, wait a moment. Passing explicitly both today's
date and the settlement date could (emphasis on "could") remove the
need for passing a calendar to the curve.
It could also clear up the code in ImpliedTermStructure. Hmm...
I say go for it.

Bye,
        Luigi

--

[Ferdinando M. Ametrano-2]

Hi all

At 09:23 PM 4/24/2002 +0200, Luigi wrote:
>>In TermStructure zero and forward rates are assumed to be continuous
>>compounded rates: this is probably an error we did in the original
>>design, but unless we fix it everywhere this is the way to go.
>I agree that the short-time goal is consistency with the present design.
>However, "everywhere" is just PiecewiseFlatForward and the formulas in
>DiscountCurve and such.
It's more deeper than that. Continuos compounding for zero and
instantaneous forward rates is assumed in:
ZeroYieldStructure::discountImpl
ZeroYieldStructure::forwardImpl
DiscountStructure::zeroYieldImpl
DiscountStructure::forwardImpl
ForwardRateStructure::discountImpl
ForwardRateStructure::zeroYieldImpl

[btw: I think I spotted a bug in ZeroYieldStructure::forwardImpl: shouldn't
'r1+t*(r2-r1)/dt' be 'r2+t*(r2-r1)/dt'?  ]

Also should we agree that discrete forwards must have the same compounding
rule as zeros (see my post to quantlib-users), then tmy proposed
implementation for TermStructure::forward(Date, Date) assumes continuos
compounding too

ciao -- Nando

[Andre Louw-2]

Nando wrote:
> I did a few changes on TermStructures. I also did a few changes to
> DiscountCurve:
Agree with the changes, thanx.
> In TermStructure zero and forward rates are assumed to be continuous
> compounded rates: this is probably an error we did in the
> original design, but unless we fix it everywhere this is the way to go.
Unless I'm missing the boat entirely I don't necesarily think it's an error,

it's more a question of a call that was made. I mean conversions can be made
where
necessary either way, not so? Why fix it if it ain't broke?
> Please let me know if after my patch DiscountCurve still
> works the way you wanted. I can always roll back my patch if needed.
Works fine.
> I would also like to introduce another change: I would
> require the user to provide a discount grid starting with the first
discount
> equal to 1.00, so that we can assume that the first date is the settlement

> date. I think this would be safer. Here's what I have in mind:
> [...]
Agreed, is safer than assuming it matches the input.
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Ferdinando M. Ametrano-2]

At 01:15 PM 4/25/2002 +0200, Andre Louw wrote:
> > I would also like to introduce another change: I would
> > require the user to provide a discount grid starting with the first
>discount
> > equal to 1.00, so that we can assume that the first date is the settlement
>
> > date. I think this would be safer. Here's what I have in mind:
> > [...]
>Agreed, is safer than assuming it matches the input.
done.

ciao -- Nando