different curves ... this does seem like a normal way to go about
things (to me).
quotes - this is exactly why this feature was invented).
----- Original Message ----
From: Luigi Ballabio <
[hidden email]>
To: Chris Kenyon <
[hidden email]>
Cc:
[hidden email];
[hidden email]Sent: Wednesday, April 30, 2008 12:19:00 PM
Subject: Re: [Quantlib-dev] seasonality for inflation term structures
On Tue, 2008-04-29 at 01:50 -0700, Chris Kenyon wrote:
> We want to give users with the ability to provide a seasonality
> correction to the term structures.
>
> The get/set is defined in the base InflationTermStructure class as:
>
> public:
> void setSeasonality(const boost::shared_ptr<Seasonality>
> &seasonality = boost::shared_ptr<Seasonality>());
> boost::shared_ptr<Seasonality> seasonality() const;
> bool hasSeasonalityCorrection() const;
I'm not sure that I like the setter. Of course observability can be
implemented correctly, but I'd prefer curves to be immutables. What I'm
worried about is the following scenario:
Handle<InflationTermStructure> ts;
InflationInstrument I1(..., ts);
InflationInstrument I2(..., ts);
I1.someResult(...); // for
some reason, calls setSeasonality()
at which point the value of I2 changes. We had such a bug in the past
when calculating the implied volatility of an option would modify the
underlying equity process for other instruments. It wasn't pretty.
My proposal of adding seasonality by wrapping the curve was so that I1
could (if needed) take the passed term structure, wrap it, and use the
wrapped curve without modifying the original one.
Thoughts?
Later,
Luigi
--
All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore, if
you can't get them together again, there must be a reason. By all
means, do not use a hammer.
-- IBM maintenance manual, 1925