Re: [Quantlib-dev] seasonality for inflation term structures

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Quantlib-dev] seasonality for inflation term structures

Luigi Ballabio
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



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Reply | Threaded
Open this post in threaded view
|

Re: [Quantlib-dev] seasonality for inflation term structures

Chris Kenyon-2
I like the idea that curves are immutable.  However, I'm not keen on
introducing another level of coding structure.  A simple solution
would be to remove the setter.  This way curves are immutable,
and if a user wants different seasonalities they can just provide
different curves ... this does seem like a normal way to go about
things (to me).
    I don't favor using Quotes for seasonality data since seasonality
should not be changing on short timescales (there are no market
quotes - this is exactly why this feature was invented).
   Comments anyone?

Regards,
Chris


----- 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



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Reply | Threaded
Open this post in threaded view
|

Re: [Quantlib-dev] seasonality for inflation term structures

Ferdinando M. Ametrano-3
Hi Chris

On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <[hidden email]> wrote:
>     I don't favor using Quotes for seasonality data since seasonality
> should not be changing on short timescales (there are no market
> quotes - this is exactly why this feature was invented).
>    Comments anyone?

I understand your reasons but I am in favor of Quotes, especially
since they would be the main hook for sensitivity analysis, i.e. in
order to calculate sensitivity with finite differences you just tweak
the Quote value, recalculate the NPV of your portfolio, then restore
the original value.

The observability combined with the lazyness ensure optimal
performances and general easiness for this approach, which is probably
one of best features of the QuantLib design.

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Reply | Threaded
Open this post in threaded view
|

Re: [Quantlib-dev] seasonality for inflation term structures

Chris Kenyon-2
In reply to this post by Luigi Ballabio
Hi Nando,

that makes sense.  This also makes setSeasonality methods safer because if you are using Quotes it is a signal that you may be changing all sorts of other things.  OK lets go that way because:
1) helps avoids unexpected side effects (i.e. given the QuantLib setup you know that if you change a quote, or if you have to make new ones, then you are doing something drastic);
2) permits sensitivity analysis (which is also what get/set are about).
This implies:
1) Instead of vector<Real> we use a vector<Handle<Quote> > for seasonality factors.

Have I understood what you meant?
Any objections anyone?

Regards,
Chris


----- Original Message ----
From: Ferdinando Ametrano <[hidden email]>
To: Chris Kenyon <[hidden email]>
Cc: [hidden email]; [hidden email]; [hidden email]
Sent: Thursday, May 1, 2008 6:19:32 PM
Subject: Re: [Quantlib-dev] seasonality for inflation term structures

Hi Chris

On Thu, May 1, 2008 at 10:01 AM, Chris Kenyon <[hidden email]> wrote:
>    I don't favor using Quotes for seasonality data since seasonality
> should not be changing on short timescales (there are no market
> quotes - this is exactly why this feature was invented).
>    Comments anyone?

I understand your reasons but I am in favor of Quotes, especially
since they would be the main hook for sensitivity analysis, i.e. in
order to calculate sensitivity with finite differences you just tweak
the Quote value, recalculate the NPV of your portfolio, then restore
the original value.

The observability combined with the lazyness ensure optimal
performances and general easiness for this approach, which is probably
one of best features of the QuantLib design.

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users
Reply | Threaded
Open this post in threaded view
|

Re: [Quantlib-dev] seasonality for inflation term structures

Luigi Ballabio
On Fri, 2008-05-02 at 00:57 -0700, Chris Kenyon wrote:
> This implies:
> 1) Instead of vector<Real> we use a vector<Handle<Quote> > for
> seasonality factors.

Or we use either.

Luigi


--

The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users